The Hard Thing About Hard Things and the State of DevOps Report, 2021
Remind me, Ash, did we set a date for this episode?
Ash:I don't know. I think we might have a conversation about that way back in the mists of time.
Ian:The mists of time?
Ian:Yes. So what that really means is that our next episode will be coming out,
Ash:don't say a date don't say a date,
Ian:on the January 7.
Ash:Can it just be beard noise?
Ian:It could.
Ash:Don't don't mention dates.
Ash:I'm still really paranoid about dates and estimate. We need to talk about estimates as well, don't we? Yeah. We do. So if you get to the bottom of my rampaging paradigm about saying when something will be done.
Ash:Maybe it's because I'm paranoid about when when when people say things will be done, what they mean is they're gonna have done some programming.
Ash:Which year was that, Ian?
Ian:I'm I'm fairly sure it must have been very recent.
Ash:Before COVID. Right?
Ian:I think that might have been December 2019 when we said that.
Ash:A good year.
Ian:Yes. There were five episodes of What a Lot of Things in it.
Ash:There was. The statements about estimates still still hold true as well.
Ian:That might be the wrongest estimate I've ever made.
Ash:That's okay. I don't think it's the wrongest estimate I've ever made.
Ian:Well, you were very wisely not making an estimate.
Ash:As in the wrongest estimate you could ever make is making an estimate.
Ian:That that was my mistake, was making an estimate.
Ash:Yep. And we all paid for it. In total. Hopes and dreams.
Ian:Yes. Fortunately, we have no project manager because they would have had to have fallen on their sword or something.
Ash:Yeah. That's true.
Ian:Where did we go?
Ash:I had to venture out into the into the world of money making. Alas, the podcast world takes a little while to get going. So I just needed to regenerate a fund or two, and now I'm back.
Ian:We're very happy to hear it.
Ash:Where have you
Ian:been? Well, I have been unfaithful. I have made another podcast.
Ash:Yeah. That's true.
Ian:In the interim period.
Ash:That's true. Although This one won't be the same.
Ian:It's far more daft and pointless than this one.
Ash:Yeah. This could be equally daft and pointless.
Ian:I'd like to think it's more daft than pointless. I have some follow-up from the previous episode. Can you remember what the previous episode was about?
Ash:No. Christmas?
Ian:It did come out about Christmas.
Ash:It wasn't about Christmas.
Ian:It wasn't about Christmas. No.
Ash:I seem to remember talking about your digital death.
Ian:Yes. Particularly macabre. Yes. And that is what the follow-up was about. Although, I'm not sure how helpful you'll find it.
Ash:Oh, is this my Twitter handle?
Ian:It is your Twitter handle.
Ash:That I desperately covered my Hannibal Lecture.
Ian:I I did go and look at it the other day and it still has a man whose single tweet is very condemnatory of a particular footballer.
Ash:Very judgemental.
Ian:Very judgemental. So, our listener, Mark from Basingstoke, who actually was named in the previous episode as well, but obviously that was some time ago, so he and we might not remember. But his angle on this was that as you have lots of documentation proving that your name is Ash Winter, you should perhaps just phone up Twitter and say I've lost the password to my account, Ash Winter. Please, can you give it to me?
Ash:Well, I have to prove that I still think that Samir Nasri is a one of them. It happens if they ask me that question. Have you has your opinion changed of Samir Nasri? I know he's a wonderful chap.
Ian:Yes. I think you should definitely go for the positive in that.
Ash:Yeah. Absolutely.
Ian:I did feel as though, you might stumble if they wanted to know what your email address was when you registered the account.
Ash:It might be Samir Nasri's email address.
Ian:In fact, maybe it's him.
Ash:Maybe it's his self account.
Ian:He picked your name as a kind of fake name.
Ash:Yeah. So who would be called Ash Winter?
Ian:Yeah. Yeah.
Ash:How ridiculous.
Ian:I think you may have nailed it then. I guess it's up to you. You could try that if you want.
Ash:It seems like it's a good question,
Ian:doesn't it?
Ash:My general interest and, desire for that Twitter handle has diminished a little because I was quite excited that it would be in, like, the first sweep of Twitter reclaiming handles, but apparently not. I don't know if my status cake alert for that Twitter handle is still running. I hope it is. I haven't logged into status cake to check for a little while, but that's how excited I was about that Twitter handle. But I think my excitement has diminished, as in I've not set up monitoring and alerting around that further Twitter handles.
Ian:Did your monitoring and alerting, use Twitter's APIs to register the account for yourself if it detects it goes back?
Ash:No. It didn't it wasn't self healing. That's still in my personal run book to wait for that alert to go off and then to manually fix it to be automated later Yes. When there's time. When there's when there's fewer features to deliver.
Ian:Well, who knows though, there might be a further Ash Winter lurking in the sidelines who's just slightly more
Ash:A bit more on it.
Ian:Diligent than you.
Ash:A bit more
Ianxxx:on it.
Ash:A bit more a bit more awake and aware. Well, good luck to them is what I say.
Ian:Yes. Yes. Good luck to Ashwinters everywhere.
Ash:Absolutely. If you get to that Twitter handle before me, you obviously wanted it more than I did.
Ian:Yes. Yes.
Ash:And I'm not gonna argue with you.
Ian:Some follow-up. There you go.
Ash:Thanks, Mark.
Ian:Given that this is called What a Lot of Things, we should talk about some things.
Ash:Yes. Let's talk about some things. Ehud, you were gonna go first.
Ian:Oh, to monopolize the airwaves.
Ash:Begin the internal external monologue.
Ian:My thing is is another book. And I realize I've now done this twice in a row because the last episode that was A mere mere two weeks ago or whatever it was was, was also a book. So and I have read quite a lot of books in between now and then. In between now and then. In between then and now.
Ian:This book is called The Hard Thing About Hard Things.
Ash:Okay.
Ian:And it's written by Ben Horowitz who's a venture capitalist. He Who's one of the partners of Andreessen Horowitz, which is a a venerable venture capital firm. And it's about how to be a CEO. It's quite good. I thought it was quite interesting.
Ash:Okay.
Ian:I don't think I'm gonna be a CEO particularly, but
Ash:You have your own company. That's true. You can declare yourself CEO.
Ian:That's true.
Ash:Isn't that how most CEOs do it?
Ian:They just say, I'm the CEO.
Ash:I'm the CEO now.
Ian:The problem with this as a thing is it's probably about six things because the book is about quite a lot
Ash:of Yeah.
Ian:Different things. So it talks about when companies go wrong, talks about one of the chapters is called taking care of the people, the products, and the profits in that order.
Ash:See, I always have, like, a intake of breath when I see such statements. So I just think it's a nice thing to write in a book. So, yeah, I I must admit I do have quite a lot of cynicism about such such statements. But, you know, there are there are other examples. Is it Dan Price, the the CEO who dropped his wages from a million to $70,000 and everyone got the same basically, everyone gets paid the same in the company, pretty much.
Ash:Oh, there's a minimum level of $70,000.
Ian:Yeah. I do think I remember that. And actually, they were very serious about that even down to people in what might be thought of as quite lowly job roles. Some CEOs are different than others.
Ash:Most CEOs that I've met, they're kind of necessarily psychotic, in some ways because you probably wouldn't, like, volunteer yourself for that role unless there was unless you there's something slightly unhinged in some way. So although I guess I'm just sort of making a personal comparison because, like, from my point of view, I'm like, well, yeah, that that type of role doesn't really appeal to me. So maybe I'm just generalizing and saying, well, anyone who it does appeal to is an absolute psycho,
Ian:which is probably not true. I think that, psychos are probably generously represented
Ash:Yeah. I think so.
Ian:In that population compared with, the regular population. Yeah.
Ash:Yeah. I was just wondering what what was like the if you had to pick one thing about the book, what would it be that stood out for
Ian:you? I think there were a few a few things I thought were interesting. Maybe I can't get it down to one, but I'll I'll try and keep it to to not very many. One thing he's talking about is kind of corporate politics, which I think is quite interesting. And his observation was that companies, often with very apolitical CEOs, can be very political environments.
Ash:I guess it depends on what you think of as as politics. For me, it's like a discussion between two people is partially political, isn't it, at work? Because you both got things you want to achieve and, you know, agendas that you bring. So you can't help it. I think there's are you when people say politics like that, do you just mean, like, bad behavior, if you know what I mean?
Ash:Scheming.
Ian:He did.
Ash:Rather than politics.
Ian:Yeah. Maybe. I mean, his he he kind of his definition was around people advancing their careers or agendas by means other than merit and contribution. Any of that kind of underhanded I I I certainly think scheming. Yes.
Ian:Let's let's go with scheming. I don't think he was against people talking to each other and working together. I think it was just the the negative aspects of of the way that happens, which I think was and he had some quite there was some quite good sort of content about that. So things like, what should you do if somebody comes and asks you for a pay rise? What, Ben Horowitz was his point was that if you give someone a pay rise because they ask you for one then you're basically he he would say you're encouraging you're encouraging behaviours where people are doing stuff for themselves and not for the good of the company.
Ian:And he so he saw that as something that actually can produce political behaviour.
Ash:I guess it depends on the on the reason, doesn't it? Because if you've been historically underpaying, then that's one thing. I've seen a few examples where a company has been historically underpaying and then people have turned up and said, hey. You should be paying me a bit more. And it's like, well, you know, you're not doing it for the good of the company.
Ian:One of the things he's very passionate about in in his writing is about making a company a good place to work. So that the people that work there will go to work and feel fairly rewarded and will find it, you know, that it's possible for them to reasonably do their work and and to, you know, to not be beset with obstacles that that prevent them all the time. All of those kinds of things. I think I mean, the thing about pay rises, I guess was part of that, you know, having a a less political company is kind of part of that. Another thing that was interesting actually sorry.
Ian:Do you want to talk about
Ash:that a
Ian:little bit more? So another thing I thought was interesting was he's he's very interested in making sure that people do that companies train people. And there's kind of a it was quite interesting actually because he was giving example of, he was when he was running a company and he he basically rolled out some management training which he delivered. Where he's basically saying telling the managers, this is what is a good manager, this is what a bad manager looks like. And by the way, it's absolutely imperative that you do one to ones with all of your reports every week or every two weeks or whatever it was.
Ian:And he basically mandated that for all his managers and then he's telling the story that he discovered that this particular manager had not talked to any of his reports for like six months. And he sort of thought about how to handle this and what he actually in the end did was that he got that person's manager to come come to him and then he had a conversation with him where he was kind of outlining he was sort of saying, why do you think I come to work? And, there was a lot of to ing and fro ing about various various answers and theories and things. But what what he was saying was he comes to work, but the thing that motivates him is making the company a good place to work. And by the way, did you know that this manager that reports to you hasn't spoken to any of his reports for for six months.
Ian:Yeah. And by the way, if if he hasn't spoken to all of them in the next twenty four hours, then you and him are both going to be fired.
Ash:As a manager, your one to one is probably one of the few tools that you actually have to influence things, assuming that you're not hovering over every task that every of your direct reports is always doing because otherwise that that signals, like, omnipotence and psychosis. But the whole I mean, I suppose there's there's a bit of a there's a cultural thing. Is is this in The US?
Ian:Well, he yeah. I mean, that's the context. It's certain value.
Ash:So it's the there's something there, isn't there? Because, like, obviously, in the in The UK, this whole, you know, you do this or you'll be fired within twenty four hours, is it really a thing? And
Ian:Yes. Do do this, or we will begin a disciplinary process that will take the rest of
Ash:our lives. You have the right to appeal, and you have the right to, be represented, and you have the right to bring a union in. All the things that stop really crazy stuff, like two people being fired summarily happening. But, yeah, it's a very different different culture, isn't it? Yeah.
Ash:The training thing is quite weird as well, isn't it? I mean, I do agree. Like, when I first started out as a manager, I was just like, here's some people, manage. And it was like, okay. What what what?
Ian:I had that too.
Ash:What does that mean? So I went and, I found a podcast called, Manager Tools and started listening to it. And part of it, it was it was like corporate America, so there was some of that strange, I'm gonna fire you tomorrow, sort of rhetoric in there. But some of it was actually really good, and it talked about, you know, how to do a one to one or at least how to put a framework around it and the importance of of a one to one because they're the only tools that you really have in order to to influence proceedings and how to use them to talk about the future as well as what you need to do now. That was really good.
Ash:And I think that would be a a a welcome benefit to lots of new managers especially to get some guidance on that. That's a that's a good thing for a company to do because there's probably lots of managers like me or new managers like me and like you when you were a new manager. I was like, I've got no idea what I'm doing, but also I can't be seen to not know what I'm doing in some ways. I need to, you know, I need to look convincing. And you kinda piece it together for yourself.
Ash:So it's really nice, I think, that a company, like, puts value on that pastoral care and career development that you get from a really good manager. So that's good. But, you know, to to go six months without speaking to your direct reports.
Ian:Yeah. But what what what does that say to them? It's just terrible.
Ash:There can be many things going on there as well, can't they? Might have an especially difficult direct report or set of direct reports. Not saying that you should avoid it, but there's always an explanation if you wanna dig deep enough, or you could just fire them the next day.
Ian:I think I I think, though, that saying something to reinforce, doing some and saying things to reinforce his very strong feeling that one to ones are very important is very good. I mean, obviously from a cultural point of view and from, you know, legal and other points of view, we might not do it here by saying, right, you're all fired if they don't fix it tomorrow. But nonetheless, something really quite quite firm to say this is a big priority for me and it must be for you as the people that work for me Yeah. I think is actually, was is is a good thing for him to have done.
Ash:Could have just said that, couldn't he? I like what you just said. I prefer that too. I prefer that to you're fired to tomorrow if you don't sort this out.
Ian:I know. I I probably unfairly abridging what he actually said. But, yeah. I mean, I think your your point about, you know, the Silicon Valley culture being quite different to what, you know, the world Yeah. We both live in is is, is a very good one.
Ash:Yeah. And it is interesting, the point about, like, wanting to climb as well. Because when I look back on my my own career, I climbed for a while and then got disinterested in climbing, but got ambitious in other ways. It's always interesting to hear, like, counterpoints and, like, different paths and how a CEO might deal with if they, you know, if you have a culture where people are trying to climb, it's a dangerous place, isn't it, I guess? I guess that's what he's saying.
Ash:Yeah. It could have some serious, like, negative effects on on your culture because the climbing becomes it becomes at someone's expense, doesn't it? You're climbing on top of not assisting if it goes to its its, you know, the worst conclusion that it could go to.
Ianxxx:Mhmm.
Ash:So, yeah, that's, basically so it's a really interesting point, because I guess to create a culture where it's just all sort of naked ambition, it sounds really terrifying, doesn't it?
Ian:It does. Yeah. We could talk a lot more about all the different things in here. He makes some interesting points about scaling, and he's got this whole philosophy about rather than not rather than suffering from the problems of scaling, you just kind of try and hold them at bay so they happen more slowly. And he's got all these different stuff that he says about that.
Ian:He talks about organisation and designing an organisation. And that was really interesting because it's about starting off not from what divisions do people have and who are the people I want to be in charge of them. It kind of starts off from what needs to be communicated and what knowledge is there that has to be shared, and what decisions will have to be made often. And then only then getting to, to to who runs what. And I I I thought that was very interesting.
Ian:It talks about process as a a method of communication, which I thought was again was very interesting perspective. There's there's a an awful lot in there and I guess, I've stretched the definition of one thing quite far.
Ash:Well, the book is one thing, to be fair. And I do think that there's there needs to be more, like, positive examples of scaling.
Ian:Mhmm.
Ash:Because,
Ianxxx:I
Ash:think a lot of attempts to scale are often the sort of thinly veiled empire building attempts Oh. Or could consultants with frameworks making grabs at things. So I think a positive model for that is really good, and I quite like that it's kind of built around, like, where does the knowledge and the skill set rather than, you know and how does it make sense to align ourselves rather than just going straight straight in with a framework or just saying, well, you know, let's just hire 70 devs and let them fight it out. But I could I could say that I've got an organization with 70 developers in it. There definitely does need to be more positive examples of of how to do that.
Ash:Because it's it's like the big challenge now, is it? Yeah. You know, you make a team work in a way that in a way that suits your business, but then how do you do that five times, 10 times? I don't know. So positive examples of that would be great.
Ian:Yeah. And and he does he talks a lot about that. The other thing he says is quite interesting is that he sort of talks about the trade offs of organizational of designing an organization. And he basically says, however you do it, people are gonna criticize you and they're gonna be right because you just can't. So you also have to look at well, okay.
Ian:So, for I don't know. I put marketing in the same division as the product teams rather than sales. Yeah. And therefore, now I have to think about what could go wrong between marketing and sales that I need to to mitigate somehow.
Ash:They'll come up with, like, really wild dreams about products that could be, and how to sell them and then start selling them before they're even built. That's what That
Ian:would never happen.
Ash:It's already happened. It's happening every day.
Ian:Except for all the time.
Ash:Apart from all product decisions ever.
Ian:Yeah. So I I recommend this book. I like I'm recommending it as someone who's reading it not because I think I'm gonna be a CEO of some scaling start up. I don't I didn't read it from the point of view of being, I do find it interesting in because of its organizational design implications and and the discussion of of why some things are done in the way they are, which is which is interesting. And it kind of joins on in a funny way to Team Topologies, which we, we talked about in episodes of Your that was a great, great episode.
Ian:That was that that without having ever read it, it still lives with me as something I think about a lot, and eventually I will read. Okay. Well, that was that was my thing. Can can we remember how we do this?
Ash:What the transition between between two things? I I think we'd put in, like, a comedy side effect, wouldn't we? Sound effect, not side effect.
Ian:Side effects. Comedy side effects.
Ash:So many
Ian:Something to be explored there, isn't there?
Ash:But then Ash comes in with a segue saying, oh, hey. I've got a thing as well.
Ian:Oh, that sounds that sounds familiar, actually. That sounds like the kind of thing we do.
Ash:Yeah. Yeah. Just kinda burst in
Ian:I will
Ash:change the whole tone of it. Away from hard things to really easy things. Things that are dead easy to achieve.
Ian:Just Easy. Easy things. The easy thing about easy things.
Ash:The easy yeah. My book is The Easy Thing About Easy Things. Great thing about easy things is that they're so easy.
Ian:Yes.
Ash:Yeah. And if you can't achieve them, then that's your problem. Yeah?
Ian:Yes. Yes.
Ash:Sorry. I'm starting to go Ben Horowitz there. If you can't achieve them, then you're fired tomorrow. There you go. You can play the role too.
Ian:I've I feel I've, I feel I've I've harshly, edited what he said. I feel as though he's probably,
Ash:That's okay. Probably as bad
Ian:as I'm I'm currently making out. What's the next thing, Ash?
Ash:So so I tried to keep it topical, and the state of DevOps twenty twenty one report has come out.
Ian:Not even 2020 or 2019.
Ash:2020. We skipped 2020. There was no DevOps in 2020.
Ian:Literally the bleeding edge of 2021.
Ash:Yeah. Absolutely. 2020 has been consigned to the void.
Ian:So It was in a state.
Ash:Yeah. Well, yeah, that's true, actually. So this, this this report kinda piqued my interest because, it talks about having an internal platform team. And the gist of this was that you kind of have these middle performing organizations. The state of DevOps reports define organizations by certain criteria in terms of, like, well, I guess, the big four, the number of deploys, and, you know, and the meantime to recovery and cultural and all kinds of other measures.
Ash:And it describes this problem with these middle performing organizations who've attempted a a DevOps transformation, and they've sort of floundered a little bit. Maybe gone back to, like, the original habits, having a just an OpsOps team, for example.
Ian:Did they did they create a a DevOps team? Is that how they did it?
Ash:And, apparently, the the State of DevOps report says that if you have a successful platform team, and this is literally can get them out of their funk.
Ian:Oh, wow.
Ash:So read that however you like. And I think this was kind of interesting to me because I've in the in the last couple of years, I've worked at places with a few different sort of patterns of platform teams. So I kind of recognized a bunch of the the symptoms in the report that they talk about.
Ian:K. Can we zoom out quickly? Sure. What do we mean by platform in this context, and what do we mean by platform team?
Ash:The internal platform, and this is, the definition used in the report. So it's a foundation of self-service APIs, tools, services, knowledge, and support. Delivery teams can make use of the platform to deliver features with reduced handoffs. So that might be like container orchestration tooling or observability tooling or knowledge management, making sure that it's well understood what a particular service does and what how to how to assist it if it fails. And then also trying to push along, like, organizational objectives, like, I don't know, you want your teams to have more test automation in their pipeline or something like that.
Ash:It's quite a wide remit is the only thing that strikes me.
Ian:I was slightly entertained when you were speaking there because I wanted to answer this question about what do we mean by by these things. I I Googled and I I found myself on Martin Fowler's website, who is a very learned gentleman of of IT delivery and something big at Thoughtworks. And, he, in his, in his blog, had written a definition of of of what a, a platform is in this context. You'll be amused to hear that his definition on his blog post was a digital platform is a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product.
Ash:So there's some alignment there between whoever wrote whoever put that those words in the report and, Martin Fowler. To be fair, if you're gonna be aligned with someone, Martin Fowler is not too bad. Right?
Ian:No. No. Agreed. It does go on to say that autonomous delivery teams can make use of the platform to deliver product features at a higher pace with reduced coordination.
Ash:There you go.
Ian:You see? So a strong divergence at the end there between coordination and handoffs. Yeah.
Ash:I prefer coordination. But one of the things that so he talks about these middle performing organizations and having a a successful platform team can really help. And one of the things that I found really interesting about that was that any blockers, if you state them as cultural, that's not helpful, as culture is thought of as immutable. So if you said, I'm gonna pick on testers because I am a tester. The testers always want to do lengthy release regression testing before anything goes out because there's, like, a culture of doing that.
Ash:It's just found it really interesting that that statement, especially the culture is thought of as mutable. So I don't know. I guess I I I think it probably has I think culture has drag about it. It takes time to change, but I don't know if I've ever thought about it as immutable. What do you think?
Ian:That's I mean, that is really interesting. I mean, changing culture is hard, but actually I think what you're the kind of thing you're doing when you're trying to implement some of these kinds of things is that you're changing behaviours. If you change enough behaviours then culture with a lag will follow on behind. Especially if you're changing things in such a way that people are being enabled by it. And so that instead of feeling that the changes are impeding work, the changes are making work easier and better, then Yeah.
Ian:I think in the end that will change culture. But I think it's the behaviours and the the other things around that that you have to start with.
Ash:So I just found that a very sort of interesting statement. It seemed a bit I kind of hope culturally obviously, I I acknowledge I always acknowledge that it can take a long time to change something like that, but I have a I have a hopeful feeling that it can change and and for the better as well. I try not to think of it as immutable.
Ian:Yeah. I I think there's a thing that humans do where we have ways of labelling things to get people to accept a set of assumptions about them. And you see this often in, Twitter mobs and things like that where if we call you this thing and we can get a number of people to agree that you're this thing, then we can treat you in a particular way or it's okay to do particular. I I mean, I I I don't want to dive into any of those rabbit holes. But I think saying that something is cultural is what is almost a way of saying, and we can't change that so let's not bother thinking about it.
Ian:I think it's a way of labelling it in a way that means that it's unchangeable or or maybe someone else's job. So I I think it may be a bit of an excuse to do that or a bit of a Yeah. A get out.
Ash:The other bit that intrigued me as well was, about those organizations like in the in the middle performing layer are being much more well, it kind of intrigued me because I didn't particularly agree with it. So basically saying they're risk averse. So they and specifically, they call that being scared of a continuous delivery approach, which I assume that they mean trying to get one piece flow often from idea to production or however you want to however you want to describe it. It's kind of false risk aversion, I guess, is my disagreement with it because it's like, well, by storing up your releases, obviously, you're storing up your risk as well. That argument needs kind of flipping on its head a bit.
Ash:You need to redefine the risk. The risk is not releasing, not releasing, not not releasing.
Ian:Yes. I kind of get that, but I think that their that their fear the fear comes from you need some things in place to do continuous delivery. So you need your good solid automated testing for example.
Ash:Yeah.
Ian:You need you need a reliable back out mechanism that can back things out as quickly as they they get put in. And when you are sitting in a brownfield kind of situation with some horrible legacy app, then the mountain to climb to put those things in place, When people come and say, oh, just start doing continuous delivery, it it I I always feel a bit as though it's more complicated than that. And actually, it is possible to start doing continuous delivery and it to be a catastrophe because you haven't got some of those building blocks in place.
Ash:Yeah. Don't automate it until you understand it.
Ian:Because you'll
Ash:just be automating your misunderstanding, which, you know, may work out terribly for you. So I think there is a little bit of that as well. But, again, it comes down
Ianxxx:to
Ash:that foundational work. Again, that's where the platform team might come in for these organizations as well. But I do think we need to frame the conversation around releases and risk a a bit differently as well.
Ianxxx:So I
Ian:think agree.
Ash:Stored risk is probably worse than, like, you know, small large stored risk is worse than small released risk. Yeah. So so, yeah, I think there's there's there's definitely, like there's there's some interesting points within the within the report itself about these middle performing organizations and how do you sort of get to that next level. So all this kind of got me onto thinking around the platform team patterns of my recent past. I've worked with three variants of that pattern.
Ash:So the first one was the project driven one. So as in, we will build your platform, but the project still pays for everything.
Ian:Oh, no. That's just that's impossible.
Ash:Weird sort of clashes, sort of conflicts of interest between delivering the thing for the project while also trying to build self-service platform. It didn't
Ian:work very well.
Ash:You just ended up with a yeah. You just ended up with an ops team who fell under the cosh all the time. Project teams were just asking them for stuff all the time, and then you didn't have access to anything. And it was just it was just horrendous.
Ian:Yeah. It's the incentives are just terrible because project managers want to, reduce costs of their projects. So they so they say, well, we're not gonna use this platform because that's an extra cost, and we haven't budgeted for it. And meanwhile, the oh, it's just us it's just all the incentives make it doomed to fail if you make the projects pay for it.
Ash:I mean, that kinda speaks to the, like, the the cultural part as well, doesn't it? So, well, we've always paid for things in projects. That's that's a really tough one to overcome. I do have a lot of and if I was tasked with setting up a platform team in a project based organization, I'd I'd think twice, to be honest, about doing the job because it would be incredibly hard. So the second pattern was hidden when within delivery teams, platform teams.
Ash:I like this one. So we had, like, a like, a couple of platform engineers who were just hiding on scrub teams doing platformy things while product people, like, stopped the corridors looking for people to build features, asking what everyone was doing. And they're like we were just going, like, distract the product people with, I don't know, shiny things. So that was a really interesting one as well. It was kind of a way to get the thinking established at least.
Ian:So I
Ash:guess for me, one of the things with platform teams is that you want you wanna, in principle, you want to help the delivery teams or the the product teams take as much ownership as possible, not tag on to the ownership. It was a slightly nefarious way of trying to get that thinking going, but it wasn't too bad because they were on the teams as well, which I think is quite a big a big thing too.
Ian:It it seems as though maybe if you're going to evolve into a platform team, that's where you'd start is is you'd be seeing projects doing things which really really helped other projects. And and maybe feeling as though actually, if we funded this separately and made it an official line of work that we do that we do, then, you know, you you were saying, well, we could have this benefit that we've already had but multiplied up. And that kind of is a bit of a business case for it as well.
Ash:And then the final one was individual as a platform. Oh, dear. So in Team Topologies, they talk about the thinnest viable platform, but, you know, having one person doing all the all of that sort of work. Yeah. That that just doesn't work, does it?
Ash:You know? And it's like a it's like an emotional disaster, a mental disaster for that person as well, and probably physical disaster for that person as well.
Ian:Harks back to Brent in the Phoenix Project who who was?
Ash:Yeah. I think that's it. It's it's like the classic individual as a platform. Like, that you're not
Ian:It's a
Ash:Everyone's waiting for you to do stuff.
Ian:You become a bottleneck in in extreme way.
Ash:And, you're not sharing. I think, one of the things that that nags me a bit about platform teams is that you need, like, unicorns, at least one or two unicorns to make it work. So you wanna treat it as a like a product. Right? So it's got, like, goals and KPIs and all those other things.
Ash:Yeah. I think you need a a sort of relatively special type of product owner, if you like, for a platform team, you know, that has, like, the technical chops to do it and also has an understanding of what makes a great product and, you know, how to, research your users and find out what they need and all that. It just sounds like those types of endeavors need some fairly hard to come by people is kind of what always springs to mind for me when I think about platform teams.
Ian:It is hard to hire a lot of those those kind of people unless you're a very, very big cool company in in some way. But it Yeah. I think it is interesting actually. I think you have to look at it. I mean, effectively the developers are your users and you have to understand them and empathise with them and do all the things that you do when you're looking at your end users and how your products are helping them.
Ian:It's the same. There's no no difference. I mean, design thinking absolutely applies in that scenario.
Ash:Yeah. Because that's one of the things that that's talked about a lot in certainly in Team Topologies and in in the state of DevOps report is, like, the developer experience and trying to improve that because, you know, there's some pretty frustrating developer and, well, and tester experiences out there, you know, where you feel like you can't make that much of a difference. Everything is kind of behind behind a a locked door, and there's certain people who have certain amounts of knowledge that you need, but it's very hard to get that out of them. So you end up with a lot of inertia in your role, which can be quite frustrating. So I think that improving that developer experience again, it's it's turning the these concepts, platforms, platforms of product developer experience into real things, isn't it?
Ash:And that's where you need your your product knowledge as well or at least your ability to go and, let me say, empathize with your users and find out what they want and what they're frustrated about and spend some time with them and which, again, in my experience of existing platform teams, that's been the thing that hasn't really been there. It's just always been, yeah, we could spin up a a billion AWS instances, like so. But, you know, I can do that. What Are you trying to solve the problems that we that we really have? You know?
Ash:What do you wanna know? Do you wanna come and work, you know, pair with me while I test and see what see what's going on? You know? See where the pipelines fail, see where there's bottlenecks or, you know, incomplete environments, you know, components missing, what whatever it is or environments that haven't scaled as much as they as as they should to become a a decent load test, you know, all those types of things. So it's, it's very much like turning it into that that product product mindset rather than just, we're going on to AWS mindset.
Ian:I maybe it's not at all relevant, but I've always struck by this quote that, Bill Gates allegedly said. So when Facebook back in the whenever it was was going through its various funding rounds and it got to this kind of $15,000,000,000 1, you know, it's the big one. They were all going on about how they were platform, this and that and the other. Bill Gates apparently said that's a crock of shit. This isn't a platform.
Ian:A platform is when the economic value of everybody that uses it exceeds the value of the company that creates it, then it's a platform. Yeah. And I guess I'm quoting that because I feel as though it somehow applies to this but there's quite a lot of mapping to do between a team inside a I I feel like that is for a platform team to be really succeeding, that's the kind of thing it it it needs to be able to point to.
Ash:Yeah. I think the, the thinking behind that quote is it is sound thinking to me. And I would I would agree with that as part of, like, having a, putting the effort into the platform. You want it to be, greater than the sum of its parts, don't you? You want it to be so that every team is self serving themselves with what they need when they need it.
Ash:If you're still serving them, then in the project driven platform team, the platform team just got bigger
Ian:and bigger.
Ash:Yeah. Like, literally up to, like, a hundred platforms. Oh, no.
Ian:Yeah. That's not a team. It's a loose confederation of warring tribes.
Ash:So the report, talks about three ways of improving things. It said to do the five whys with your leadership. It's like
Ian:Or at least do as many whys as you can before they get you get fired. Yeah.
Ash:Exactly. They're they're duck. Yeah. The five whys with Ben Horowitz. Why am I fired?
Ash:So That poor. And then the second one was take a long look at who you hire and their attitudes. I mean, that's kind of, evergreen advice really, isn't it? And then they kind of mentioned, like you said, you know, like you said about having, like, an application that's been hanging around for a while. It's just like a nudge in the right direction with a little bit of improvement over time.
Ash:One thing I quite like is the seventy thirty principle for features versus making the work work better. The most successful teams are spending at least 30% of their time on making the work work better. Again, it's it's good advice. And we I think we as certainly, we as sort of technologists and and technology leaders probably need to get a bit better at selling it because I've worked on far too many teams where it's like, technical debt, that's the developer's problem, not the product's problem. You know?
Ash:It's like, well, that's your problem. It's like, oh, there was a system outage at the weekend. The technical teams are taking a good hard look at themselves as to why this happened.
Ian:There they are, stood in the corner right over there thinking about what they've done.
Ash:Yeah. Exactly. So, well, we were kind of all involved in this outage actually when you think about it. All of our decisions led to it. But, again, it's these are the things that I think we always struggle to sell.
Ash:Yeah. So, yeah, I really enjoyed the state of devil's report. It kind of spoke to my recent experience with platform teams as well, which made, made me smile wistfully. No.
Ian:I think that's a that is a great thing. And, it's it's very deep as well. I I feel sure we could probably talk about it for another another three hours. So, sit back and relax, listeners. We're in for the long haul.
Ian:That was a great thing. Thank you very much.
Ash:Thanks, Ian. I enjoyed that. Got a lot of things off my chest there. Her bell's released. I can breathe again now.
Ash:That must be nice. Okay. So that was two things.
Ian:That was two things.
Ash:And just two weeks after we initially promised to do episode
Ian:six. Approximately.
Ash:But this is the joy of, of doing testing. Right? Because as a tester, you don't have to estimate anything. You just ask how long you've got.
Ian:And then and then they reduce it.
Ash:And you do some testing. Yeah. But then you do some a little bit less testing. And then you go home, you put your feet up, job well done. The world falls apart around your ears.
Ash:You think, well, you know, my estimate wasn't wrong, was it? I asked you exactly how long I had.
Ian:Yeah.
Ash:It was your estimate that was wrong.
Ian:Yes. You
Ash:See? I've cracked it. Estimation. There you go. Hashtag test estimates.
Ian:You heard it here first.
Ash:You heard it here first and last.
Ian:There'll be there'll be a book about estimating that we will write. It'll come out shortly. I estimate in two weeks' time. It's just slightly hollow enough now. Okay.
Ian:So what do we have to say? What do what what do we what did we used to say when it was the end of the episode aside from bold claims about when the next episode would come out?
Ash:There will be no claims. We decided on no claims, didn't we?
Ian:And in fact, perhaps if we do that, then we can have a no claims bonus.
Ash:No claims bonus. We could we can get each other
Ian:a a
Ash:big Yes.
Ian:As a bonus for making
Ash:no claims. But not not buying into the the, you know, military industrial estimation complex that could drive our lives.
Ian:Buy into them.
Ash:Ian's life.
Ian:A bit harsh, but okay. So we we have quite a pile of things anyway. We have accumulated a number of things since the previous episode, and so there will be more episodes, but we're just not gonna say when. Yeah. Because, you know, we've learned our lesson.
Ian:I've learned my lesson. Brilliant. Alright.
Ash:Alright. I think we're done.
Creators and Guests
