Innovating in the software kitchen: Ownership, responsibility, and agency

Juan (00:00): And you care about it because down the line, you want to keep your team's capacity focused on innovation and feature iteration, and not support or maintenance.

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I've been to depths that remain classified. And Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Enjoy your time in the DevOps Sauna.

Marc (00:46): Hello, we are back in the sauna. Super excited about our guest today. Before, I have my usual cohort, Andy Allred. Hi, Andy. 

Andy (00:56): Hello, hello. 

Marc (00:57): Hello. Hello. So I have to say we got our guest today from listening to one of our favorite podcasts ourselves, the guys over at Troubleshooting Agile, some old friends, Jeffrey and Squirrel. If you don't listen to them, give them a listen. They're a awful lot of fun. But this is the DevOps Sauna podcast. So what we heard from the debugging agile that really got us going was it was so good that they had Juan Pablo Buriticá back for two episodes more. So three total episodes, it was called Vague but Valuable. And there was a term that really stuck with me called Navigating Ambiguity, which I see an awful lot in the tech space. It seems like sometimes the more brilliant an engineer is, the more difficult time they have with navigating ambiguity. And certainly, we also see it at the management level. But hey, Juan, hi, I'm so happy that you joined us today. And you're speaking at an entrepreneurship conference. And you still took some time for us. So hello, Juan, nice to see you.

Juan (01:57): Marc and Andy, how are you doing? Thank you for having me. It's great to be here in Finland.

Marc (02:02): Fantastic. So tell us a little bit. Maybe we could open. I know that you're speaking later today. Tell us what you're into. And what are you talking about lately?

Juan (02:13): Sure. So lately, I have been spending a lot of time trying to help different sorts of functions and organizations build better products. I think many of the engineering challenges start outside of engineering. And so, you could say evangelizing on behalf of engineering about how to collaborate with that function. So yes, I am today to like a purely business conference, like entrepreneurship startups. It is based in Bogota, Colombia, where I'm from, but you have about 600 founders entrepreneurs, who want to build products, and do a bunch of great things and innovate. And a challenge I believe they tend to run into a lot of like getting their technical teams to do what they think they need to do. Getting into this very non-intuitive process of building software and achieving the outcomes that they need and not the ones they think they want. I think that's a huge thing. And yes, even though right now, in Latin America, I think this is a global problem. On one end, you have folks who are perhaps throwing over the fence fully fleshed out requirements in sort of like isolating technical teams who should be really close to the problem. And at the other end, yes, there's also a responsibility from the technical crew, which is the emphasis on trying to get really well define backs, like, hey, tell me exactly what the product needs to do it. And instead of approaching the problem, and the user with curiosity, and going all the way to the user heading with the actual problem that you're trying to solve, and how do we use technology to do that. So yeah, I'm here, I'm excited. And also, I'm excited to be in two places at once, here over time, then over there in Finland, weather in Bogota is actually perfect for a sauna. It’s actually, it's a little cooler than you'd imagine. Because we are really high up in the mountains. So it's perfect time for a sauna, thank you for having me.

Marc (04:08): This is a really interesting topic that you brought up about the overbaked kind of requirements or fully fleshed out requirements because in the early days of agile when we looked at the manifesto, and we thought, wow, this is really, really great. And then management didn't understand it. So we did it anyway. And then when management started understanding it, the biggest freedom that people were given was like choice of processes and tools, ways of working within the teams, which then creates a whole set of pathologies about now everybody does things differently, and everybody has their own Jenkins instance, or whatever. And now there's all this fragmentation: but what people really want to do is solve interesting problems and deliver those and see those in production and see customer joy coming back from that. So this thing really hits home about getting the requirements to well-baked. It's like if we could instead give people a development platform that allows them psychological safety and experimentation and the ability to test things in production even, but then give them a little bit more creativity in how they're going to solve the customer problems and even discover those. I think that's a really important topic.

Andy (05:17): I think a lot of times Marc and I go on different customer engagements. And when we get in, it always starts with, we need help with this tool. Yes, okay! We know that tool, we can help you with that. And in the conversation, we try to dig out, what is it you're really struggling with? And where is the actual pain points that humans have? And yeah, this tool might be the thing for that, but we might want to change something else, actually solve a bigger problem, or make this tool completely unnecessary. So this, here's the detailed JIRA issue with x and y and z that the developer needs to do, sounds fantastic if it's a manufacturing plant: but software isn't manufactured, it's created. So we need to look at it differently. And sometimes I get so lost.

Marc (06:02): I think you've done some work, or you have some speaking, Juan, about software factories. So how do you see this software as a manufacturing or as a factory topic?

Juan (06:16): Sure. Yeah, I have a talk, I'm giving in a couple hours. That is, as you can imagine, unfinished, finished in my head, but unfinished in the slides. And the talk goes towards encouraging founders, executive leaders, or folks outside of engineering, and even those from engineering, who haven't worked at product engineering crews to build product engineering teams if what they're trying to do is to innovate. I think if you're trying to solve problems that haven't been solved before, then you need to take a scientific approach. A scientific method approach, which, to me, the product engineering, and product development is using the scientific method to solve user problems through software. What tends to happen a lot, and yes, of course, a lot of what I'm the most familiar with is Latin America, or the States. But you get the these very excited founders want to build software, they don't have a technical co-founder, or technical sort of ownership at the leadership level. And their understanding of software is really through these physical models of manufacturing. Someone decides the solution, and then we give it to others to build it. And that, I don't think works really well when you're trying to innovate. I think there is a space for software factories, if you want to call them like that. But it's not innovation. And before I, like go really hard on software factories, or like these sorts of outsourcing shops. For example, I love outsourcing problems where I should not become an expert. For example, if I'm having scaling problems with my database, and I need to tune it, I need to do a bunch of things. But this is not like a capability I need to develop, then I go out, I reach out to Percona or to someone else, hey, look, come and do analysis and solve this problem for me. You've solved it so many times that you know better how to do it. So that's a really, really good use case and it's not my competitive advantage knowing how to scale databases, unless that's my business. It's not my competitive edge. So that rewrites or migrations of specific technologies, keeping the product static, those are really the-- I've had really good experiences having someone else solve that problem for me. But when I'm trying to solve someone else's problem, I need to embrace it, I need to take ownership and not just me. But I need my team, who I hire, who I pay hundreds of thousands of dollars to solve problems, I need to put them right in front of the problem. And so that's the encouragement to actually build product engineering teams internally versus software factories where you're handing them off something that you want to do like a very specific outcome. Not the outcome, but the output, the result seems to be like really the fun, I want this interface and I want it to be red, and I want to click here and I want this to happen to sort of the analysis is lost, and you waste a lot of time and money. And so, I'm going to pause there a bit since I've given the overall picture of what we're talking about. We can dive deeper any way you want.

Marc (09:28): I think the interesting thing is that when I think of software factory, one of the angles that I think of is flow. Getting the software to flow and that type of flow being something that you have the ability to do exactly what you described, Juan, which is the scientific method, you've researched an idea, you have some hypothesis, I think the customer might like this or might do this. So then you experiment in production, maybe with a small batch of customers or a region or something like that, you see if indeed, the customer does behave the way that you expect, or maybe they even invent something else. And then based upon that output, then you're able to decide, you know, what do you do next. And like, there's this kind of continuous flow through the factory of new ideas and innovation.

Andy (10:21): But in software development, a lot of our terms and processes and everything are basically taken from manufacturing. We talk about the delivery pipelines and everything. And if you're building a car, you need to build 17 widgets, and it takes 13 minutes per widget. So how long does it take? And then we take that analogy, put it into the software and say, hey, we need to build three more extensions. Well, an extension takes us two weeks. So in six weeks, we're done. But it doesn't always work like that. And then we have on the flip side, the old cliché tell me, what problem are we trying to solve? Okay, well, let's do a two-week sprint and figure out which Linux version we should use for this. <laughs> So it's like, there's a sweet spot in the middle, but how do we find it, we are focusing on where we add value, but we're not going so far that we're saying, okay, this is very strictly what we need to do. And here's our flow, and you do not deviate from it so we can have that innovation.

Juan (11:21): You're spot on. I actually have a background in culinary arts. And so, the analogies that worked really well for me in software is creating food as a comparison for software. So I think the last comparison, I had a tweet recently about something like this, but I think a really good example is software is not let's get together in two weeks, take a bunch of food, try it many times and see what a customer likes. That's not accurate, and it's also not, hey, cook this whole thing for me, like I imagined this dream dish, cook it for me and then it has to come out perfect. These two things don't work. It is actually... So first, you do need a business strategy. So the hypothesis is, hey, look, I believe that there is a space for a chicken dish in our menu or in this store, or in this locale that can sell really well and we can make it profitable. The margins will be useful, or it will be significant to our restaurant. It's like the menu is a portfolio of products. And they all have to work together. So you know that you don't make a lot of money out of steak, but the pasta, you can mark it up a bunch. You balance those things out. So it comes from a business strategy. Once you say, all right, like there's a hole for this, or we need a product that fits these things. And there might be a desire of it in the market, then you go into your product development thing. So you try a few recipes with chicken. And is it roasted? Is it pan seared? Is it the breast? You test it out. Eventually, you perfect it. In that cycle you might have cooked chicken before, but you have not cooked that specific dish. So that's why your estimates are always going to be wrong because roasting a chicken is very different than roasting 12 chickens. And then the operationalization of that dish is different. I can’t believe I got that word. I'm proud of myself. Usually, Spanish gets in the way. But yeah, so the product development and operations of that also product are different stage. And if you really come to think about it, shipping food and shipping software is really, really similar in many ways. And landing more the fact that you have to, also you have to have some taste. Because anyone here, if we're all given the same ingredients, the exact same ingredients, we will produce very different dishes, they may look different, they will taste different. And the reception of the users will be different, even though we started with same thing. So it's also non-deterministic. But I really like getting engineers to think about the taste of their products like hey, did you like this? QA to me is not click, check. No, like, are you tasting your product? Are you using it continuously? And would you buy it? So I think the point where we were started was like yeah, the manufacturing analogies how they will work. I've heard people talk about, like the composer orchestra, there's a few others that are a little bit closer to the process of shipping software. And I think we can also take advantage of that.

Marc (14:42): I love this analogy. You know, in our house, there's a bunch of dishes that we make pretty often and fish tacos is one of those, from Baja, so what happens every now and again is we don't maybe have the same ingredients that we had before. So we try something new and then it's like you try some yogurt in the sauce instead of mayonnaise when you're making the kind of tartar sauce kind of thing. And then you realize, wow, this is really good. And then you look at the label, and you realize, not only is it cheaper, but it's also got less calories, and it's just as good. So it's kind of like this experimentation, you don't know where the innovation is going to come from, until you pick up a set of ingredients, and you try to cook with them. 

Andy (15:22): And I think it's interesting you said that, okay, you don't have this, so I'm going to use that instead. A lot of times the best innovation comes out of having constraints. So instead of telling development team, just do whatever you want, you tell them, you do whatever you want with this, and this and this in mind, and then it forces them to look at the problem differently. And that's when the real cool innovations just spring out of nowhere, but it's not really out of nowhere.

Marc (15:54): Hi, it's Marc again, the DevOps conference is coming to Stockholm and Copenhagen. If you'd like to come to our Scandinavian conferences, please have a look at thedevopsconference.com. Now back to the show.

Juan (16:11): Yeah, actually just found the tweet that I had. And it was a response of someone complaining about quarterly planning and the terms in the context of agile. Their tweet goes something like, hey, we're a company that is agile, but five minutes later, it's time for quality planning. And so, all teams need to agree on what they'll do in the next three months. And I think we also from engineering, we tend to misunderstand the different time lapses in which we need to work because agile is not like, hey, and going back to cooking context. Agile is not I'm going to go into kitchen and put randomly stuff on a plate every two weeks, until someone pays for it and figures it out. There is a strategy, so we go back to the venue. Look, over the next three months, we'll make chicken as accessible part of our menu, what? We don't know if we will. We already know what we're trying to get out. And that's where the planning and the execution come together. So that's another important bit that I tend to highlight. 

Andy (17:21): And I think also it's important what phase we're in. So when you're cooking chicken the very first time, this new dish, you're focusing on one, and you need a lot of creativity and a lot of possibilities and some constraints in order to like, okay, this is the one, but now you have the one and now you need to learn how to make 12 of them at a time because of your evening dinner rush. So if you're making something that you already know how to make and just trying to repeat it, your process necessarily will be different. So sometimes you do need to have this quarterly planning, this is the big picture of where we're going. And sometimes you do need to have this whatever it is in the next two weeks, let's figure it out based on this, and then it's not either or it's a yes and. And how do you find the right balance that we seem to struggle with?

Marc (18:11): Juan, I believe you have a really interesting topic coming up in one of your talks called Scaling Without Dying. And I was telling a similar analogy, but I'll change it into the food category now, which is that the thing with software that many companies don't understand, and you've got all these entrepreneurs there and man, when they hit production, are they going to get into an interesting situation. But with software, it's like every time you add a new item to the menu, you still have to make all of the previous items. You add a new ingredient, and you will never get rid of the old ones almost ever. So the amount of maintenance that it takes in order to just keep up with all of those different things that you are creating and adding all of the time can create an awful lot of toil. So how does this fit into your scaling without dying type of topic?

Juan (19:06): Awesome. Yeah, the title is a little grim. <laughs> I think that our listeners, of course, don't have an image, but I'm like a heavy metal punk looking guy and I like using skulls and stuff. So that's where that comes from. And the talk’s title is How to Scale a Tech Team Without Dying in the Process. The purpose is, since the audience is still is very business entrepreneur, what I intend to achieve is to encourage them to give the space to their technical teams to do things well early on. And by well, I mean more in the product delivery or software delivery pipeline than not. Usually, when people call me either to explore a new role or for advice or for anything, they do so because they have big problems that they have no idea about. Those tend to be you feeling the same. Like, hey, how can I get more output of my team. And then we have all these different ways of approaching, they've tried many things. And then they've tried to do all the different blog posts or recommendations or doing. I don't know, like extreme programming. So there's all of these things and they realize, like, hey, none of this stuff is working, but how do we get better at it? And what I've found is there's a few things that if you get right early on, that allow you to learn really fast and iterate really fast, and also keep your support and your toil under control, you're probably better than most early-stage company. So if you allow, and not just allow, if your dev team also has some experience about how to do this because it's also like unintuitive. One of my favorite examples is like unit or like early testing or test-driven development. It is unintuitive for folks who haven't lived through it, like spending more time writing tests, and dealing with how do you set up your runner and all this stuff. And for every feature, you have to do additional work, and my God, and you're not seeing the results. And so that gets sacrificed at the beginning because that's the investment phase. You have really no return. And it seems like a waste of effort and stuff. I think we all know the story. But then two years later, you're trying to make a change. And your codebase is so brittle and so fragile that you can't.

Andy (21:33): It's not even always two years, it's not even always two years later. Marc and I are working on a little app for a customer and I had everything dialed in. This is just something really small and really quick. I'm not going to bother with tests. And we delivered the first demo. And everything failed because I put a typo in and I had no way of seeing that beforehand. And then I was like, why didn't I just write some tests from the beginning? I know that, I advise people to do that. I coach people on that. 

Juan (22:04): So it's right. It's always those things if you get quality monitoring because I don't even like QA, it's quality monitoring. Eventually, you will know that something important broke, that's what you care about, and you care about it because down the line, you want to keep your team's capacity focused on innovation and feature iteration, and not support or maintenance. And rather than rebalancing your portfolio over time, which tends to happen by habit, like you just have to hire more people. Because you started with a team of 10, greenfield, everyone was just building lovely stuff, suddenly 80% of the crew is sending out fires and sort of reacting. And then to recapture your feature development capacity, you have to hire 10, 20, 30 people more, but then you hire people who don't have expertise in what has been built, you don't have quality monitoring infrastructure. And you end up with a mess, with a muck, you could have prevented that early on. So one of the messages on Friday is going to be like, invest in either training your crew on how to test, give them the space to set up this stuff and encourage them to deliver software in that way. Like it has to come from the top and there is value there. And it's not intuitive to you because you've never shipped software. And by that, I mean to you, Ms. CEO, or Mr. CEO, who just has an idea. That's one that we go into experimentation infrastructure, get feature flags on board. It's such a simple thing. And it helps you manage feature releases, it reduces the risk of you breaking stuff out, like a product, you don't even actually you shouldn't even build those yourself. There's like all these services now that provide you with support, like, LaunchDarkly or PostHog or cool stuff. And that helps you also adopt a lifecycle of features. If you're testing out something early on prototype, three customers get to see it, and it doesn't have to be perfect. And you don't have to write a manual and your customer support team doesn't even need to be trained on it. Your engineers and your designer, and even PMs, all in the lifecycle of that feature. And then you gate. So now it's a private beta. Okay, we're going to open 100 people, cool. What do we need in order to onboard 100 more customers? Well, maybe a little manual or maybe like API documentation or maybe a support email like less things once you validated that look, if it didn't work, turn it off, didn’t work, remove all the code behind the feature flag. See you later, you got it. If it worked, then how do you often more people and what is required for that? You put your marketing needs, that's when marketing can get involved. And that's how you also get out of the problem of sales selling stuff that they shouldn't be selling yet. This is this is not something you can talk about unless we are in private beta, or AGA. You can't talk about it because we may take it away and you've thought about it. It's your responsibility because there're explicit expectations around the process that we have. And it's easier to manage. And that's something that should come, or the feature flag, the experimentation infrastructure is part of the target delivery pipeline, it should come from engineering, the rest of the organization should give the space for engineering to have it. So that's that the mix. And there's a few others like that CICD platform deployment, just get a few things right early on that will keep you from dying along the way, as you scale your team. 

Marc (25:48): There's a chart that we have in our materials, about transformations whereby everything moves really fast until 1.0 in production because they didn't do all of these things. And then when 1.0 happens and production happens, the best developers leave and they go somewhere else, the program manager or project manager gets promoted and goes on to create a mess in another place. And then some people are left behind that weren't part of that original thing. And now all the toil has stacked up and the ability to maintain and monitor and keep that thing running was never built in from the beginning. Cool. So there's a couple of questions that I want to spend a little more time on this. We traditionally on this podcast have two questions that we ask at the end. This is the first time so Juan, you inspired us to put those into the podcast here. He's got his hands up on the video \o/. So I have a thought experiment. Juan, you've been a software leader for how long now? 

Juan (26:43): I think 15 years or something like that. 

Marc (26:47): Yeah. So I ask this question. This is a thought experiment, as a leader, and I'm a trusted team member. And the team is gathered here. And everybody around us all of the other team members are complaining about a problem. And then I raise my hand as a trusted team member to you, Juan, our leader in this thought experiment, and I say, Juan, I can take care of this problem. What do you say?

Juan (27:12): So I'm going to assume we're going to keep this very cryptic around the specifics of the problem. But I think the first question I would ask would be something around, well, if you cared, why haven't you? "<Ooh!>"If you're, if you're a leader--

Marc (27:30): You're the leader, I'm a trusted team member.

Juan (27:32): You're a trusted team member, but there's two things. One thing is leadership, another thing is management. I am the manager likely, but leadership comes from different places. And if you're a trusted team member, here's a bunch of assumptions. You're someone who has some seniority or you've earned that trust through somehow. Likely, through leadership either in the technical space or in other spaces. And so, then I'd say that would be my first question, if you can, why haven't you? Yeah, I'd start there. Probably in a less aggressive way where I wouldn't throw you on the bus, but something around like, hey--

Marc (28:13): I can taste the rubber right now. And I can smell the diesel from being under the bus. <laughs>

Juan (28:20): Cool. Why haven't we approached this? I would like to understand, if you have a solution, why is it needed out there? Why has it come to us having a discussion about it?

Marc (28:34): Well, I'm going to have to play along on question one because there's two, so I'll have to play along a little bit. I really like this idea of quality monitoring by the way. I usually talk about the differences between quality assurance and quality control. Most of our quality assurance is actually doing quality control after the fact, quality assurance being preventing the problems in the first place. But I think the monitoring is how you do that. So our monitoring, Juan, showed that we have a problem. And if I take these guys, and that guy said I believe that I can solve the problem.

Juan (29:07): So you need staffing. You need support. You need resources.

Marc (29:11): Yeah, I need a few people in order to solve the problem.

Juan (29:14): What is preventing you from taking that up?

Marc (29:18): Well, it just came to us here and everybody else is complaining. But I'll take the initiative, and I'll take care of this with a little bit of help from a few of these people. 

Juan (29:27): Cool. Let's go for it!

Marc (29:28): Excellent. Okay, thank you for pressing me actually, that's putting me on the spot, that was a new one on this one. So let me ask this follow up question. The more important question now. What we've established is that as the leader, you asked some follow up questions. How did this get here? And I said, yes, I'll take care of it. And you said, yeah, I trust you to take care of it with the resources that you need. So now, how do we, Juan, get the other people in the team to act more like you and I next time. 

Juan (30:01): So it goes to the question that I asked, why haven't you solved it yet. It goes to the point where you have the ownership and the responsibility and the agency. Like my role here as a leader is not to tell you what to solve. I'm thinking from the executive position more than the line management. But I'm here to endorse your decisions. If I'm in the room, or when I'm in the room, it is to validate your assumptions or to give you air cover. If you say, hey, Juan, I want to solve this problem, but it means that I will take these four people who are working on something that seems to be important, but I got this. And so, then I'll say, all right, thanks for the heads up, it now becomes my responsibility. I will give you air cover, go at it. And so, when someone comes to complain, hey, why aren't you working on the stuff? Look, we have this problem. The team is on it. And if there's differences there, look, I made that choice. It wasn't the team; I made the choice. I reprioritized. I had the scope and so I've given you air cover. And I've also given you safety, I've made you feel safe. You can start feeling risk. So what I encourage there is my team doing a few things. They know that I've got their back, no matter what. The only important thing about me having their back, let me know. No surprises, please. Because the opposite is my peer comes is like, hey, why aren't you working on this stuff? I'm like, what do you mean? Yeah, no, he's like, four of your people of your crew are working on all these other problems, and be like, shit, good on the initiative team. But what about the heads up? Now, I can't give you that air cover. And, of course, I am not going to throw you under the bus. But then I have to throw myself under the bus. I should be informed about what my team is doing. I don't know. And so, then that creates safety. So I encourage or I give the space for the team to do that more by creating that safety and the sense of ownership. I think that all the problems that a team is facing, whether they're technical, or they’re organizational, or they’re people related belong to the team as a collective, and not two individuals because I believe that software engineering is an emergent property or like software is an emergent property of a crew. You can program and programming is an individual activity, and you can do it by yourself. But software is the output of collaboration. And so, anything that is beyond that requires collaboration. And so, any problem you're having is my problem as well. And so being really crisp around that. It's actually like this perspective is what led me to write that talk and post that landed me on the podcast of what's called Troubleshooting Agile. I've noticed that dichotomy ICs expecting the manager to solve all the problems. And then but also I see wanting to be leaders and senior in sort of like shifting responsibility into management. And then management also being- it's not working. That capability framework I published earlier, the experiment I did goes to that, hey, look, here's what I expect you to do as a team, whoever does it doesn't matter. These are the problems you have in the team. One is finding out what work to do. If your manager isn't doing it, are they busy? Can you support them? Can you help them? Or do you really want to just be handed tasks? If so then this is not a team for you. We're not going to get really far if that's what you expect to be done at any level, starting your career or as a very senior person. I think I've extended myself, but that's how I tend to approach it.

Marc (33:42): Absolutely brilliant. There's a lot of things that I liked there; I want to highlight a few things. The first one is the reason that I was inspired by you to ask this question was because of the navigating ambiguity because there's a very small percentage of people that I ask this question to, and they get so frozen from the lack of information that they can't even ask a follow up question. The most common things are, like our CEO was like, I trust you, do it, what do you need? And very, very similar. And then I like the fact that your teams have and your method has enough agency in the team members that you expect them to solve the problem. So just let you know, so that you can cover the- a good leader takes the problems on and gives the team the safety in order to be able to follow them. So I think that was absolutely exceptional.

Andy (34:34): I was just going to say we talked about air cover. We talked about I'm here to endorse your decisions, psychological safety, software is the output of collaboration, test driven development, feature flags, operationalization. I already know this is like Marc's favorite episode ever.

Marc (34:53): It absolutely is. And I'm going to give it a go as well. Operationalization. It's a fantastic one. It's been super cool to have you here. I'm a huge fan. I love your style. I love your leadership and management as well. I like the approach that you have with things. And it's been super great to have you on the podcast.

Juan (35:15): Thanks so much. I'm really flattered and honored to have visited you in Finland, and thank you for having me. 

Marc (35:22): All right. And thank you, Andy. 

Andy (35:24): Thanks. It's been great. I really enjoyed this.

Marc (35:26): All right, this has been the DevOps Sauna. Thank you, and look forward to talking to you next time. Before we go, let's give our guest an opportunity to introduce themselves and tell you a little bit about who we are.

Juan (35:44): I'm Pablo Buriticá if you manage to pronounce that. I was born in Bogota, Colombia. I live in New York City. I have been working in tech and software for a little bit over a decade or so. I jumped into engineering fairly early on accidentally. And I don't have a formal computer science background or anything like that. I grew up with our computer that I broke. And no one around me knew how to fix it. So I learned how to fix it. And I also would buy these magazines with Linux distros. And I would install them and destroy my computer and learn about kernel and drivers and stuff. But I studied pharmaceutical chemistry and biotech in one of my lives. I did not finish any of that somewhere along the way out, though, studied culinary arts and ran kitchens. So my earlier management career was running kitchens. And I get a lot of the inspiration of running teams through being on the line, on the cook line with my crew. And also onboarding new cooks. The support like all that. A lot of the theory of running teams even like the brigade, the chef's brigade, the communication, the acknowledging, the methods, a lot of stuff that I've implemented in my teams comes from there. I've worked on the state startups, some that don't exist anymore, some that are still around there like Splice, which I hold very near and dear to my heart. And I've also worked at mid-sized and public companies. So I ran engineering for Latin America at Stripe. I most recently was working at a company called Ritchie Bros, the public company that sells heavy machinery online and wanted to become a tech company. So that was a really wild and fun ride to try to figure out code bases that were older than me in COBOL, in mainframes places. Fascinating. Right now, I am on a small POS, the different my next gig, but yeah, I enjoy product engineering and product development and all that stuff. And I guess in my spare time, I build software communities in Latin America. So I started JSconf Colombia 10 years ago, this year, we're having the last one. Years of organizing conferences gets to you. Yeah, I guess I like paying it forward. I don't think I am self-taught; I am community-taught. And I like paying that forward. So as I've invested a lot of effort, yeah, also like changing a little bit of the perspective around the globe of what Colombia is and isn't.

Marc (38:09): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (38:14): My name is Andy Allred, and I'm doing platform engineering at Eficode.

Marc (38:18): Thank you for listening. If you enjoyed what you heard, please like and subscribe. It means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.