Well, I was just saying I was late to this podcast because I had to recollect some camping materials that I had lent out. We're going camping this weekend. I haven't looked at the weather, but I think it's going to be that fair high 60s, 70s or something. Hopefully no rain. But so here's my question for both of you. What is the number one thing that you would recommend taking camping? And the number one thing you would say you definitely don't need that. Just leave that at home. How about you go first, guest? The thing that you definitely need would probably be some toilet paper, right? You're out there in the woods, need some toilet paper. That is wise and pragmatic right there. Yeah. Yeah. The thing you don't need, in my opinion, would be a sleeping pad. You can just go without the sleeping pad. You just take your sleeping bag, leave the sleeping pad at home. It's bulky. It's heavy. Sometimes it's heavy. Yeah. But yeah, leave it at home. You don't need it. Wow. You know, I hadn't thought about that, but I think that's spot on because I've slept on a sleeping pad many times and you know what? It's not comfortable. So you might as well just like sleep on the ground and then you don't have to worry about that. Yeah. That's smart. We have the, nowadays we have two kids and we have the cots. We have the car camping. We haven't done rustic camping in a long time, but the cots, man, that is the technology that's really nice for camping. I enjoy that. But yeah, no pad. I like that. All right. How about yourself, Richard? Yeah. I was going to say money for a hotel. Hey. That's how I camp. Well, you don't bring his kids. So this is all just coming from a dark place. No, I think I'd have to bring something with some sort of GPS tracking because I have zero sense of George. Yeah. Yeah. My brother seems to camp every other weekend in Arizona and I think he likes to get lost, but I would get lost and be dead shortly. That's right. So probably GPS related. Either bring GPS or a small pen knife so you can free yourself from boulders should that happen.
2:01There you go. And what would you, aside from the kids apparently, what would you not take? I mean, ideally you don't bring the phone, camera, whatever, so you actually enjoy the scenario you're in. I know it's harder nowadays, but I don't know. There's something about actually putting your head up and looking around where you're going nowadays. Yeah. Yeah. That is a tough one. As the mobile device becomes multi-purpose, what with the GPS and the camera. What are you going to do? My wife still likes the traditional digital camera. So we always have one of those, which is, it actually takes really good pictures, but it always feels a little strange to use that. But I guess we'll take one of those. Well, why don't you introduce yourself briefly, guest? Sure. My name is Marisa Dale. I'm a product design manager in the Washington, D.C. office. I've been there for just over two years. I just had my two-year anniversary. Oh, two years. As the joke goes around here, you're a veteran then. Yes, maybe that's so. That's right. Well, we'll come back to, you had a medium post called the Technologist Hippocratic Oath, which I thought would be fun to talk about in the overall context of it. But first, as always, we'll go over some relevant news items. What do you want to start with, Richard? Yeah, let's see. So Amazon had a little get-together last week, sort of a little show. And so they announced a bunch of stuff, as you are wont to do at these sort of events. So a lot of security-related stuff. I threw some links here in the show notes, a new Secrets Manager, which actually has rotation of secrets, which sounds oddly familiar to what we do with Bosch and Cloud Foundry. So clearly, rotation is catching on. There's also Firewall Manager, Certificate Manager, just some good things as you're trying to actually build some of the machinery around your apps and your platform from a security perspective. So, hey, people seem to care about that. Mm-hmm. Yeah, we had a little discussion of that on my other podcast, Software Defined Talk, where I learned a fun work hack, where if you don't know something, you should just allow yourself
4:02to look unknowing in public. And I had to be like, so how does secrets management actually work? By this time in my career, I should probably know that, but I have no idea. So I took some goofy points on the board so that I could understand it, which I think is the enlightened thing to do. But yeah, that's always plenty of fun security stuff. There was a snarky register headline about the Werner guy saying, you know, this is not a sales event, and then going on to give you all the sales numbers. But what are you going to do? Marketing, am I right? What's up with those people? I don't know. And then also, I see that Riff had a milestone in the literal sense of the word, I guess. Or not literal, but it's, you know, not figurative. I've lost track of my figurative literal stack there. Anyways, they had a release coming out. And I was noticing that because I was in, as mentioned last week, I was up at the spring tour in Dallas, which was fun. It was an enjoyable event. And I think the number one thing that people asked about that we didn't have someone in the room who could answer it in a detailed way was people really wanted to know about Riff. They're crazy for the serverless. And so it's good to see that's proceeding there. We'll have to figure out maybe in the spring tour if we can incorporate some more of that in, because that's clearly a hot topic. Yeah. And that team has absolutely zero sense of marketing because they keep shipping on Friday nights at 6 p.m. Pacific. That's right. But I love it, you know. They want a clear news day. Yeah. You know, screw it. We're going to ship when we want to ship, damn it. So they ship an update Friday night. Riff is the open source function of the service platform, runs on Kubernetes, Pivotal's pioneering that at the moment. So it's just making good progress. It's really gotten to be a nice installation experience. It's gotten to be a nice point if you're a function developer, like just write your code, run a Riff command. It gets deployed to the cluster, run this on-prem, run this off-prem.
6:04It's still obviously early days. It's 0.06. So, you know, probably don't put this in prod at the moment, but love the momentum. Team's doing great work. As you say, everybody loves the serverless. That's right. Yeah. I was thinking recently, there's this bifurcation of like, we should call it function as a service versus serverless and how serverless is ridiculous. But I don't know. I feel like serverless is a cooler name. We should, we should, we should, we should stick with that. But we'll probably use Fazz. It's just, it's a, I don't know, funner brand name for it. We'll see if that position changes. Like, no sequel. Oh, yeah. That's right. Can we just, we never do it on the positive side. We're always saying what something is not, which is always fun. Man, you might turn me around with that. Because, you know, I'm trying to be a better person as I age. So maybe I should, should be, be less negative. I don't have to shut down my column at the register. And is there, is there a positive place to write tech news? I'm not sure that's possible. I don't know what the opposite of the register is. Good housekeeping. Like, I don't know what would possibly be more uplifting. Good, good glass housekeeping. We need to start that up. And then also next week is the, the Cloud Foundry Summit. You know, we had, was it last week? We had, we had Abion. No, last week we talked about our FAQ stuff. But a couple weeks ago, we had Abion to talk about what was going on in the CF Summit. And our, our session highlights, there's also the Green Plum Summit coming up. And as, as Richard summarized it, basically you should be attending, be attending a summit somewhere next week. So there's plenty of summits going on. And you remember, bring toilet paper if you're going to, you know, go to a summit. And you don't need a, you don't need the, the bed rest, money for a hotel room. And, you know, what did you want to leave behind, Richard? Your iPhone. Bring a GPS and leave behind your iPhone. You should have, I mean, the signage is good at these things. So you probably do not GPS tracking. That's right. So, so we'll be fine. And then, and then what, what's the availability zones in Azure? Yeah, I threw that one in there. So Azure added availability zones.
8:04If you're an Amazon customer, you'd say they don't already have it. Because Amazon's had that for, gosh, I think 10 years. And this idea of having multiple distinct physical buildings within a region. So if this building collapses or whatever, runs out of power, your workloads might be striped across availability zones. So that's been a feature in Amazon for a while. A lot of people have copied that. Azure just made that generally available. And what's interesting here, Coté, you and I would have to do the math if we were so inclined. But every cloud provider kind of counts their geographic reach a little differently. You know, Azure talks about their regions. And they have a ton of regions. But some of those regions only have one building. And then Amazon talks about AZs. And Google talks about whatever Google talks about. There's no normalization necessarily of who's actually in the most places. So if everyone does availability zones, maybe that starts to normalize it. But up until now, everyone likes to brag that I'm twice as big as this one or that one. But you're not factoring in square footage or actual geographic locations. It's just cool vanity metrics. So maybe we're actually going to make it consistent now. Yeah, that always reminds me of like in the early 2000s when all the hardware vendors would like try to like on the back of the magazine, they would talk about how many like MIPS they had or processing cycles. And you're comparing like, you know, Spark chips to Intel chips to like mainframe things. And it sort of like was hard to make sense of that. And they could have all those benchmarks. Man, those benchmarks are crazy. But yeah, someone needs to normalize that. You know, like I guess it's mostly for pricing. But Owen Rogers over at 451, I think he does a pretty good job of finding the commonality between all these cloud things. And he's got his pricing baskets and stuff like that. It's always fun to see what he comes out with. Well, also just as a reminder. So we not only had a SpringOne tour last week, but we've got all sorts of them coming up throughout the year. I think the next one is on May 14th to 15th in Denver. Then later on in May, there'll be one in St. Louis and then London and Los Angeles and New York.
10:08All the great places over in Asia, several places as well. And I think they're either relatively cheap. Or if you can find yourself a pivotal sales rep, I bet you can get a very deep discount. But you can go to those. And it's basically two days of, I would say, mostly highly technical talks from people about using spring and doing all the way from architecture to actual coding to the sort of lifecycle management that you have. And then you can also do, there's like an open spaces thing where you can, the audience gets to propose various topics they want to talk about. It's a nice affair. And someone on our team, Tasha, does all the catering. Excellent food. So it's not just, as they say, rubber chickens and, you know, Jason's Deli. Nothing wrong with Jason's Deli. But, you know, sometimes you want to upgrade. Get your fancy sandwiches and other meals. So I think if you go to springtour.io, I should really, it's probably SpringOne tour. I should know these things. SpringOne tour. There you go. .io. You can check that out and sign up for them. You know, before we get to the topic here, that reminds me, someone actually asked what the I.O. in Pivotal.io was for. Not like literally what it's for, for like Indian Ocean or something, but just what the thinking behind it was. And it occurred to me that it's been so long since us tech people have used .io that I don't really think about it, like exactly what it is. I don't remember who started that. Yeah, yeah, I feel like an early explanation I read was that like open source projects used to do it. And it was sort of like, one, it was cool because it was two letters, but it was also like input output or something like that. So I don't know. That's what's always stuck in my head. And then also, I forgot, we have, what is it, one more week for the actual SpringOne platform CFP?
12:08That's right. Yeah, it's time. So after this podcast, because you're listening intently, block off the next hour, write an amazing abstract, whether these are case studies, tech talks, you know, explorations of an architecture. You know, and I think the fun part this year is it's not just, well, I don't have a spring talk. I'd love to hear talks, you know, Coté and I are part of the review teams, but I'd love to see talks on just straight up serverless or Kubernetes or .NET or microservices. Of course, spring stuff's something we love to see, but we've actually broadened the agenda a bit. So you have a week, come up with a great talk, get it into the CFP. We love case studies. We'd love to hear how you're using tech, the good, bad, and the ugly. We don't just love positive, everything's awesome talks. I think each year, I mean, Coté, you see these too. We see the, hey, this didn't work right. And not even product-wise, but like team-wise. Or, hey, we tried this and it didn't work. We had to learn from it. So if you have those, please get those in. It's a fantastic show, and we hope to see you speaking there. Yeah, absolutely. Yeah, you know, I pretty much only like the talks that are the meatware kind of talks of the people and the process and all that stuff. I mean, there's plenty of other good technical ones, but I feel like those take care of themselves to some extent. So if you have some story of how you've been struggling or succeeding or hopefully both with those, I think it's, I don't know. I think, I haven't done the bubble chart, but I think it's probably one of the larger, better conferences that goes over how things are working and not. Advice for your transformational journeys. We should suggest that as the tagline. Can we fit that all on a .io site? You can do that and bring your meatware. I think we'd have amazing attendance this year. That's right, yeah. But it'll be a good conference, and we'll see if there's some new little 8-bit art that they do for various people. So all of that wrapped up. Why don't you give us a, you know, as long as you want, kind of a summary of the post that you wrote, your Hippocratic Oath.
14:09Like what, you know, first let's kind of go over what's in it. And then I'm really curious to hear about, like, how you came about wanting to write that. Sure, yeah. Do you want me to just read experts, little sections of this, or should I kind of just shoot from the hip and summarize? Yeah, yeah. It's always better to shoot from the hip. We got a very large target. No precision needed. All right. So I think the overall idea is to get back to the core of what we're trying to build and who we're really trying to build it for. And what those outputs of what we're building, what they affect, who they affect, and in the different facets of that. So making sure that we're not doing things for financial benefit or the lure of status, but making sure that we're mindful of the consequences of the decisions that we make on our products. And the impact that it has on a potential user outside when they begin using this thing. And I think that all too often, myself included, it can be really easy to forget sometimes, you know, the real humans. We call them users a lot of times. There's all these different names that we have. But we tend to whittle this down into just thinking about it in terms of just an entity, somebody with no face, no name, really. And I think that making sure that we understand the impact of real humans with real lives, with the things that we build, is really, really important. And I think that's just kind of what the oath was trying to get at. And so, like, I forget, I could easily open it up and get the precise number. But I think there's maybe, like, eight or ten different principles in there. And, like, what are you trying to capture with that? Like, what's kind of, like, the end goal that you're trying to get towards? I mean, as you're saying, like, you want to keep people in mind.
16:13And any type of, like, ethical thing has, like, some end goal in mind. And, like, to you, like, if this software is following the oath and it's done in an ethical way, like, what's the result going to look like? Like, what is it going to accomplish? Yeah, I think maybe in order to answer that, I could back up a little bit and just talk about why I wrote it in the first place. I think that the reason that I wanted to write this was mostly just personal to begin with. You know, in D.C., we have a lot of government clients. It's mostly government now. And I've been working with them for the last two years on a lot of really complex systems that have a really big impact on a large number of people. And that's felt very consequential to me. On top of that, I have a young child who is, you know, I'm starting to watch his interaction with technology and how he's adapted that very readily. And how, you know, hook cycles can really get him. He's just especially vulnerable to hooks. And I think all of that was just sort of culminating into wanting and realizing that we didn't have any oversight or any ethical frameworks as technologists to really think about what are the implications of what I'm using here? These tools and these these tools and these these powers that I'm wielding as a designer, as an engineer. And I realized that I think that there had been a few other people who had talked about it. And I was also thinking, why is there not a coordinate or some sort of something similar to a Hippocratic oath, which medical doctors use once they graduate from medical school as sort of a fallback to, you know, am I making the right choice and questioning yourself in the moment of, you know, is this really what is is going to be helpful for my patient and not just helpful for me?
18:18And I was just thinking and realizing that we could use something like that. That would be really helpful for myself initially. And then I so I wrote that I used the Hippocratic oath, the medical version as a template and created basically thought by thought, line by line. Something somewhat of a coordinate for technologists. Yeah, you know, you know, it's it's, you know, going through them, right? Like like it's it's you can kind of reverse engineer what you're saying that if you're working on these, well, in your case, government projects that have a big impact. And at some point, you're sort of like, holy crap, like this has a huge impact, right? Like like it's so you start to try it a little more carefully. And and then also, like, I'm curious, sort of like if I were to clump together the principles, there's there's a for something that's sort of saying what is the here are some principles for thinking about the impact that that your work has on people. Right. How it could negatively and positively affect their life. There's also like kind of a smattering of I don't know what I would call like inward facing things, like how how one should think about themselves, not necessarily like like the users they have. Like, as as I guess I was in my subconscious, like sort of connecting to right, like there's not being ashamed that you don't know something and like getting help from other people to get input to it. And then also there's the part of, you know, you know, the one preceding that of like there's I should think about this being a craft that I have and instead of something else. And it's it's it's like what was your motivation like for putting sort of here's how you should think about yourself types of things? How does that fit into the overall goal? Yeah, I think what I was going for was really trying to get people to ask a couple of more things of themselves, you know, mainly why? Like, I think, you know, as technologists, as designers and engineers and PMs, we need to ask why more.
20:23I think the question how gets asked a lot. You know, I think, you know, how I how might we how fast can we make this? You know, how how can we grab the most market share? How can we beat our competitors to markets? We ask how a lot, but we don't necessarily ask why. And I think that, you know, flipping those questions and asking why more is is is paramount. And I think that it drove some of those those points that you just pointed out. I also have been really realizing that we don't talk about saying no very often. We in the the oath I talked about, you know, we are the gatekeepers, which has also been mentioned by Mike Montero. You know, we as individuals, we are part of this collective system that is building a piece of software. We as individuals play a big part in that, even though it may feel small, we can act as gatekeepers. We have the ability to say no. And that agency should be used more often if we feel like we need to. But I feel like a lot of people don't individuals, technologists don't feel like they have the agency to be able to say no if they if they need to. And they should they should know that they they have that wherewithal. And the more that you use that agency, the better you are at at using it more often if you feel like you need to. I think too often we we say, oh, that's going to be somebody else's problem. That's not really my responsibility. I'm just here for a paycheck. We we diffuse and we, you know, externalize the blame. We shift the blame a lot. But it is on us. You know, we are an integral part of this thing being built and being put out in the world, no matter how small we feel like our role is. And we need to take onus of that. I feel like, you know, inspiring people to take more onus over the work that they do can have some really great outcomes. Yes, I thought I'd follow up with that. I mean, some good points there, especially because you named a few of the people who make up a team.
22:24I mean, there's no maybe one person in some of these balanced teams. I mean, it could go up to a vice president or a founder who says this is kind of the product we make. And this is the point to a product owner who prioritizes a set of features that may encourage certain behavior or award people a certain way or anything that we might consider even ethically dubious to a developer who builds it, to an operator who runs it, to marketing who positions it. So, I mean, as you look at the it can be easy for I would think for someone to stick their head in the sand and go, I was just either following orders or, hey, this kind of made sense for the code I was writing. I didn't zoom out to the general component of how I was maybe using data maliciously or just even kind of a sketchy way for targeting or how we were maybe even the app we were building itself is of some sort of dubious nature. So how do you look at the whole team and start to figure out how do people either take on responsibility or not just say, hey, that wasn't my fault or, you know, in these bigger scenarios where you're not just a team of one, how do you approach the ethical quandary? Yeah, and I think that that's why I diverted that back in the oath to the individual, right? Each individual knows the part that they play in building the product. So, again, that introspection is really important. You know, what is the developer who's being asked to take the settings and hide it in a potential, you know, social media platform, for example, has the ability, even though they're not the one that prioritizes the story or maybe even came up with that story to begin with, they are the one executing on it. So they have that wherewithal and that right to be able to, like, say, no, you know, like, let's push back on this. Let's think about it a little bit more. You know, privacy settings are really important. That needs to be a higher level. And here's why I feel that way. I also try to make sure that I try to leave it open as much as possible because I know, yeah, Pivotal has balanced team, PM, engineering, design, but there's so many more roles and responsibilities outside of that as well.
24:24And those are absolutely, in my mind, incorporated into this. The technologist word in and of itself feels more open to me, and I liked it. I liked that about that word. Sure. Do you feel that sometimes these things get, again, we all love it. It's funny. Sometimes it, do you think there's an impact in the fact that we like small incremental changes versus Big Bang? Which, I mean, sometimes these things do. I mean, maybe it's cheating to say they sneak up on you. But sometimes it can be a combination of things that become, I would think, the bigger ethical thing. Like, hey, let's refactor how we do our settings pages. That's not by itself nefarious. It may have maybe stuck something somewhere else, but that by itself wasn't it. But as you finally then ship and you look back six months later and go, gosh, we made it really hard to opt out of ad targeting. Do you ever think, or is that cheating? Do you know what you're doing and that's just a way to make that excuse to yourself, even though you're incrementally maybe moving towards something a little sketchy? Yeah, that's a really good question. I think there's a couple of different ways to think about that. So, at least in Pivotal's model, during DNF, I personally feel like we could spend a little bit more time thinking about outcomes, especially long-term outcomes. You know, we push to MVP as fast as we can and then we roll off to the customer. And we don't really think about the longevity of the product that we're putting out in the world. That could definitely be something that we collaborate on with our clients a little bit more. And that can be thought of as best as possible in DNF. And there could be some frameworks that we use for that. You know, what is this product going to do in five years? What is it going to do, you know, three months after MVP? What's it going to do in 10 years, 30 years, or upon its death? And those are really, you know, good questions to be asking in DNF. Now, that being said, we don't necessarily know the outcomes of that. We can't anticipate all outcomes, right? It's, we can do our best, you know, like how could this be used potentially in a very dubious way?
26:29And we might be able to generate some ideas. You know, what are the positive impacts of this? Well, we can counter that with what are the negative impacts? How might it be manipulated and used in the way that we don't want it to be used later on? You know, such as like Facebook and Russian bots, you know, accounts that aren't actually valid, things like that. Not necessarily something that they could have thought about in the beginning or anticipated, obviously. But so that comes to the second part of it in that like testing is really, really important in all of this. So even after, you know, we hit MVP and we're still, you know, pushing out features, it is so, so, so important to be still in touch with the user, seeing how the product is impacting them, seeing how it's being used and manipulated, accessing that data of knowing who's signing on and making new accounts and where those accounts are from, things like that. So that you can put some blockers in place at the point where you're detecting it earlier and being able to mitigate it right away. Because ultimately, we're not going to be able to think about all the outcomes or all the different nefarious ways that something could be used. Yeah, that raises that pulls together several things I was curious to talk about. Like one, to phrase a little bit of what you're saying in my own words, like in the same way that we would continuously monitor whatever business goals loosely defined we have with the software, right? Like are people buying more stuff or can we handle more case management if we're kind of like more of a government thing or whatever goals you have? Are we meeting the productivity targets we have? There's probably also like this continual checking in of like how evil is the stuff becoming, if at all. And we should mindfully sort of look in and see what's actually happening and not just get stuck up on the only, the performance dashboard metrics.
28:33And so like, I mean, I don't know, do you have like some examples of people monitoring for that kind of thing? I don't really, other than the scathingly obvious, right? Like foreign powers interfering with stuff they shouldn't, like, you know, spying is an easy use case. But like what are some of the other ones that you need to monitor for that might be, I don't know, sort of like subtly not cool to be happening with your software? Sure. Or maybe they're all obviously not cool. To put it another way, how would you like, how would you monitor for that and check in on it? Yeah, sure. Well, I mean, I think that inevitably you're going to be getting feedback from users. I think users will be your sort of canary in the mine, if you will. Well, you know, if there's some sort of AI that's starting to come up with misogynistic comments, for example, you know, your first indication of that, hopefully you'll have found that in testing yourself. If for some reason it's starting to learn these things on its own and doing that over a longer period of time where you may not be as in touch with it, your users may be more using it on a regular basis than you are. And they identify it first. There's probably some, if you are in touch with your users, they're going to be giving you that feedback right away, submitting it through an app. You know, if you're doing testing with them, it's going to come out in interviews, things like that. So I think that it's like, again, it comes back to being in touch with the end user and always having that product like in front of them and seeing both like in the short term and the long term how a product is behaving. I think very often we put new features out in the world, we test them, we make sure, sure, short term looks good, like release it, let's go. And then it's sort of just off on its own out in the world.
30:33Well, there's not so much longitudinal studies done about those feature sets over the span of months or even years, potentially. And we could do a lot more of that to really understand, okay, what is this data that we're getting back from the long term on this feature set? Is it being successful? Is it behaving in the way that we want it to behave? Yeah, that makes sense. I mean, and it's another thing that comes up often just purely with a, I don't know, a more user centric or person centric and sort of agile approach to things, which is you should probably pay attention to your software beyond releasing it and like continually check in on how it's doing and how people are using it. And part of that is like looking at if it's not only like helping people accomplish what they want with the software, but doing it in a good way if it's behaving. And I always think analogously that it's sort of like, you know, like hopefully as my kids get older and whenever they turn 18, it won't just be sort of like a project and then I'm out. Like I'm not paying attention to them anymore. And, you know, bi-directionally we'll sort of help each other. We'll treat each other as products and be able to continually check in and improve each other versus just sort of like, you know, I think the way a lot of companies who are groups that put software out, they sort of, it's almost just like packing your kid up in a car and then waving goodbye and then forgetting they ever existed instead of remaining involved in their lifelong term. To get your project versus product mindset, right? I mean, if I'm going to stick with the software, then I'm probably looking at usage and tweaking it, especially based if things are going sideways versus, hey, this is starting to misbehave. I guess we'll form a project team in next year's fiscal budget to maybe tweak something. Hopefully that won't be as possible as people actually start forming their software teams around the products they're shipping. Yeah, and that's such a differentiator for us too, right? We work so closely with our clients to be able to carry on the work after we're done.
32:37We don't just chuck it back over the fence after MVP and then just hope for the best, right? We're enabling them 40 hours a week, every week, from the very genesis of the project kickoff. So in that way, I think that we can prepare them for these things too and testing in this manner as well. Yeah, I mean, do you think, as we talk about this kind of increasing role of software and this thing as we are keeping track of it, do you find that the responsibility might change now post-release? I mean, you know, whether it's Uber and self-driving cars, there's other things where, like, where do you start to pin responsibility on something? Sometimes you can say it's the software, but the software is not magic. Somebody wrote it. So how do you see the impact of this as software becomes more pervasive? Maybe we just haven't solved these problems yet and we're still debating it. But in your mind, how do you start to think about the kind of post-release ownership of things when something ends up going sideways? Yeah, that's an interesting topic. That's really hard because I feel like we're always trying to pin down one person or one person who is responsible or one person to blame for negative outcomes, like the Uber accident, for example. And I think what it comes back down to, or at least where my mind goes, is that these are really complex systems. You know, they're a part of a larger system, right? And they're built by so many hands and so many different people with so many different kinds of input. And obviously there's, you know, a user who's also involved and plays a big part in that overall bigger system. And it's, I think it's probably too difficult to just pin down one person to say, okay, this is the person who's responsible. We're going to, you know, make them, we're going to make them pay for this consequence. I think that we all need to take collective ownership. And instead of, you know, having our fingers pointed in, in either direction across us, you know, to, to the people on either side, you know, the, the onus and the responsibility comes back to us as individuals.
34:40You know, like, yeah, I work for Uber. I had, I had a part of that project. I had a, you know, responsibility in that too, just like all my projects in DC. Yeah. You know, the outcomes, I feel like I am in part responsible for those as well. Yeah. That's sort of like, uh, if, if, if you were to throw together, like the, uh, the five dysfunctions of teams and all the, uh, blameless postmortem work and make some sort of smoothie out of it. There's sort of the, uh, I always think one of the more nuanced things that's raised in those points is, uh, the system is what's responsible for things. Not, not necessarily like, and therefore none of us are responsible for it, but, but that, that we all need to be conscientious of building this system and building, uh, this machine that creates this output. And, and usually that means that, again, it's not that all of this isn't to absolve everyone from something, but it means that the responsibility is typically spread beyond just one individual who did something. Right. And, and I think that's a lot, a lot of the, uh, the, the wisdom of blameless postmortems is like, sure. It was like 3 AM on a Saturday night, or I guess a Sunday morning. And, uh, someone typed in a command and brought production down, but what's everything that led up to that point of absurdity that, that, that put that in place. And, and it does seem like having that broader analysis of stuff, especially whether it's like bringing down production or, or the kind of things we're talking about here, like that's really the main thing that's going to fix things. Not the, uh, the Hollywood esque, like lone hacker who screws things up. No, no doubt. I just suspect as we get to, uh, you know, again, as you saw with Uber or other things, I don't think the public as a whole loves that answer. Even though, you know, we in tech maybe have learned a bit about blameless postmortems and blaming the system when a person makes a mistake, it's because the system allowed them to. And I think people are dumb. It's just, you always look when the kid knocks something off the counter, they can't say, well, it fell. No, it didn't. Like you pushed it, right? I mean, there's something, somebody owns it. And so it's always tricky to say, well, the system failed.
36:42Okay. Well, who, who's accountable for the system then somebody has to take responsibility. And these are, these are good debates. Hopefully our listeners, even in their own companies have these discussions over lunch. Cause they probably all work with something that could have some sort of ethical side effect based on their financial stuff they're working on or government or media or whatever. So this isn't, nobody's immune from it. I hope we just start talking about it more. Yeah. I mean, whenever my son or daughter like knocks over and breaks our priceless, uh, vase, uh, they'll, they'll have to come up with their reply. Like, well, you shouldn't have put it there. Cause clearly it was going to get broken. Well, right. That's the system answer, right? Exactly. What can you do? You knew this was going to happen. Well, um, uh, so, so I, I think, I think, uh, I mean, as, as the last kind of topic. So, so you, you, you have this post here and you, and you know, I, I was interested in talking about this cause well, hopefully like many people, like I, I've been curious about this topic, uh, recently of like, how do we, uh, how do we inject more like ethical and moral thinking into stuff that we do? Cause obviously, uh, it's easy to, uh, it's easy to be negligent and have problems happen. So like, and, and there's not, I've noticed there, there's actually a lot more commentary and writing on this topic than I thought there was originally, but it doesn't seem like, uh, a mainstain of what we do. I mean, there's probably more writing and thinking on how to calibrate on story points than there is on like how to do like ethical software. So, so what do you, what do you think like are the, are the sort of next steps to, uh, like, I don't know, broaden this out and, and make it more widely thought about? Yeah. I think it could go a lot of different places. I mean, like you said, it's a, it's a pretty hot topic right now. And I feel like our industry is, is in some ways going through a bit of an existential crisis, um, kind of figuring out, you know, who we are and where we're going, because we've realized that move fast and break, break things. It doesn't work anymore. We need to slow down, you know, the, the, the things and move fast and break things ends up being people.
38:47It ends up being democracy. It ends up being security, you know, and those are things that we don't want broken. Those are things you can't put together again, or if you do put them together again, it's extremely difficult. Um, so, you know, there's a lot of talk about, uh, you know, industry oversight, or at least, uh, oversight for designers, um, having some sort of standardization, or something like a bar that you have to, you know, test and then pass, um, you know, who knows if that's going to be a thing. Um, but we, I think ultimately, you know, we, we do yield a lot of responsibility and we are really coming to terms with that right now. And I think it's good. I think it's, it's a really good time, um, before we get any farther with the technology that we already have, before we get any more advanced than we are to really stop and think, okay, what is this that we're using right now? How can it be used, um, against us potentially, uh, and how might we mitigate something very terrible before it happens? And I, I do think that whatever, um, comes out of it all, um, will hopefully move us in the right direction. Yeah. Yeah. You know, it's, it's like the, uh, the old saying, don't, uh, what, I forget how it goes. Don't, don't miss the productivity option of a crisis or whatever. I think there's a more concise way of putting it. The, uh, don't miss out on the opportunity of a crisis. Well, great. Well, well, thanks for being on to, uh, to go over that. We'll put, we'll put a, as always a link, uh, in the show notes since we didn't, uh, verbatim read the, uh, the principles there, but that, that was a, that was, that was a, uh, a great piece of content to get out there. And, and I appreciate you going over with us. Yeah. Thank you for taking the time. Sure. Well, well, as always, this has been Pivotal Conversations. If you want to find all of the, uh, deliciously exciting episodes for next week, maybe you've allowed yourself to take your, uh, what was it? Your, your, your Roxy Rio thing full of MP3s out for camping.
40:47Cause you just, you don't want to listen to crickets and you want to download some old episodes. You can go to a soundcloud.com slash Pivotal Conversations and find those episodes and some that we've highlighted. And every Thursday, usually we, uh, post the full show notes, uh, for each episode over at pivotal.io slash podcast. And remember you have one more week. If you've listened to this on more or less the day that we recorded it to go submit your thing to a SpringOne platform, which will be a fun conference to have or to be at. So, uh, you should go do that or at least come see us at one of our SpringOne tours. And with that, we'll see everyone next time. Bye-bye.