Daniel: [00:00:00] This has been Arrested DevOps on 92.9 KIL to kill.
Bridget: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Bridget Kromhout, and we have a very exciting podcast today. But first, A word from our sponsors. Arrested DevOps is brought to you by PagerDuty. In an always-on world, teams trust PagerDuty to help them deliver a perfect digital experience to their customers every time. With PagerDuty, teams spend less time reacting to incidents and more time building for the future. From digital disruptors to Fortune 500 companies, over 12,000 businesses rely on PagerDuty to identify issues and opportunities in real time, and bring together the right people to fix problems faster and prevent them from happening again. PagerDuty. Solutions before problems. DevOps shows that delivery automation is important. Our work is changing software, and software is useful after it’s delivered. So how do we develop our delivery? Is it scattered across dozens of repos? Or could we use code? Is it a loose collection of YAML and Bash? Or can we unit test our delivery too? Do we even need all those pipelines? There is a better way. When you’re tired of patching up pipelines, when you’re serious about safe delivery of code, check out Atomist at atomist.com.
[00:01:40] The worst thing about the Arrested DevOps podcast is when it ends. You’re left wondering what to do next. What are you going to listen to on your commute home? How do you occupy your time when walking the dog? What are you going to listen to during the quarterly all-hands meeting? But fear not, dear listener, there is a solution. You need to subscribe to Software Defined Talk right now. It’s a weekly podcast that recaps all the news in cloud computing, DevOps, and enterprise software. The hosts, Cote, Matt Ray, and Brandon Wichard, will keep you up to date on all things cloud while offering tips on how to optimize your Costco haul, and how to PowerPoint. It’s a fun, free-flowing conversation that will keep you entertained and informed. What are you waiting for? Subscribe to the podcast today by visiting softwaredefinedtalk.com or by searching for Software Defined Talk in your favorite podcast app. We’re here at DevOps Days Cape Town, and we’re on day 2. We’re sitting here with some of the awesome speakers and organizers. And I would first just love to have our panel introduce themselves, starting with our organizers. Cool.
Cobus: [00:02:50] Hi, I’m Cobus Bernard. I’m a technical evangelist at AWS, and we’ve been doing DevOps Cape Town for 4 years now after Bridget visited us in 2016.
Adrian: My name is Adrian. I work for a company called Salesloft where I do DevOps-type work. And as Cobus mentioned, this is our 4th year.
Bridget: So, I wanna say Cape Town might be one of the years, or one of the DevOps Days that came together the fastest, like even faster than Minneapolis, because I visited in March 2016, and by October 2016, they were— it was October, right?
Adrian: It was November that year.
Bridget: Yeah, November. So, it took them just a few months to start their very first DevOps Days. It’s very impressive. And you have your speaker, your opening keynote speaker from the very first year happens to be here today.
Daniel: Hi, my name is Daniel. I work for a company called Datadog, and I had the pleasure and the honor of being the keynote speaker at the first DevOpsDays Cape Town event back in 2016, and I’m super, super stoked to be back again speaking this morning.
Bridget: [00:03:52] Awesome. All right, and our final panelist, please introduce yourself.
Devi: Hi, I’m Devi Moodley. I work at Nedbank, one of our— one of South Africa’s 4 biggest banks, and I head up the DevOps team at Nedbank.
Bridget: So, what I really appreciated about your talk today, Debbie, was that you went right for the practicalities of, hey, we want to do an exciting transformation. That sounds like sparkles and light and wonderful. And you’re like, excellent. Now, the reality at a giant organization. And you went into some details about what it’s actually like transforming the culture and the tech at a giant organization. So, I think maybe should we start there? Let’s talk about that.
Devi: DevOps is really interesting and it’s a growing culture and very aligned with agile and principles that are difficult for traditional organizations to adopt very quickly. For us, it was— we were not a Spotify. We are a traditional bank that was established in 1888 and have very traditional values and have to comply with local and international regulation, which makes bringing in a sense of looseness very, very difficult.
Bridget: [00:05:14] So there’s immediate resistance when you say, we’re going to do something new and different and possibly faster and change things, and somebody’s flags are going up in their mind saying, whoa, whoa, whoa, whoa, what’s happening?
Devi: Exactly. And what we found was what we had to do was actually embrace those traditional concepts within our organization and accept who we were, and then start from that basis to actually introduce those new concepts. And as a bank, you have to demonstrate value before anybody actually adopts it. So, we had to really go in with our evangelists, with people that had credibility within the organization, have their show them the value and use them also as our poster boys to actually drive through the message of DevOps. At the end of the day, it is a bank. It’s about generating financial value. It is about doing things cheaper, doing things better. And that was our key driver to then really grow the movement within the organization. For as long as we were generating value, we were able to drive more investment into the practice. And that’s how we’re growing slowly but surely, one pipeline at a time.
Bridget: [00:06:42] I really like that because I think that, I mean, we are here in the 10-year anniversary season of the DevOpsDays conferences. The movement has definitely been around for a while, and it’s really nice when you say we are not one of those unicorn companies where nobody would want to try to be like them because it’s impossible. It’s like, no, you’re actually a very reasonable enterprise. And I’m curious if Adrian and Quibbes were thinking about that when they were putting together the program for this. Were you thinking there are going to be people who either are in attendance or watching the videos later who work at these sort of organizations and need to hear, what can our organization do? Like, how did you make that decision? You were like, ah, we need this voice.
Adrian: I think part of the decision was it’s quite easy to find a good story from one of these unicorn companies because there’s a lot of great stories coming out of fast-moving companies because they’re moving fast. And so, trying to balance the program, seeing a talk like Debbie’s talk from Nedbank, I think personally for myself, I think it’s really impressive that a big enterprise that is generally known to move slowly can adopt a DevOps practice. And so, I think it’s definitely a message for everybody to hear that if it’s possible in Nedbank, it’s possible anywhere. DevOps isn’t only for a certain small group. It’s for everyone. We’ve also seen a lot of adoption in many of the banks in South Africa. So, I think it’s great to have Nedbank and Devi being so involved in our community. They’re a sponsor. They spoke last year and the year before. So, it’s great to see this uptake.
Bridget: [00:08:23] I think at DevOpsDays Minneapolis, we often have people from large local retailers or whatnot because it’s nice to see the uptake in DevOps and DevOps practices from the wider industry, not just those of us who, you know, the percentage of us here who work at tech vendors are like, excellent, tech vendors, this is how we do things. It’s actually, it was refreshing and fun, Dan, to hear your talk because I think you brought a perspective that people don’t always get in tech talks. I would love if you would quickly summarize. We’ll put a link in the show notes, but if you can quickly summarize what the focus of your talk was. It was a Datadog pitch, right?
Adrian: Yes.
Bridget: Yes.
Daniel: It’s all about monitoring and analytics. No, it had nothing to do with that. So, the focus of the talk, or the name of the talk rather, was What MMA Taught Me About Working in Tech. That’s something that’s been a big part of my life is computers, and another thing that’s been a big part of my life is mixed martial arts. And I realized not too long ago that a lot of what’s been important to me in my career in terms of how I act and make decisions and interact with the world around me, I learned from training and doing martial arts. And that was basically just the story I wanted to try to tell.
Bridget: [00:09:42] Yeah, yeah, I really like that because I think that in both of your talks there were those actionable takeaways of, hey, the team matters, and the structure in the organization and the way we set up incentives. I love how you were talking about how you’ll take some of your management budget and use it to put treats at the meeting, and the meeting has educational things for people to learn more about DevOps. It’s like strategy right there. But I love that because I do think it’s not a tension between the personal and the organizational, right? It’s people are what make up these organizations. And I saw that in both of your talks. It was a common theme. Did you folks plan that as well? I feel like there was a lot of good planning.
Cobus: There was a bit. It’s always fun trying to balance the program between technical talks and more cultural talks because the cultural part is where you normally get bogged down because tech is never the problem. It’s always people. And I was actually— we were very surprised at some of the talks, even though we thought they were technical. For example, your one, where there was a lot of cultural components to it, which is awesome because I think that has more effect than actual, hey, this is how you run the latest thing in production.
Bridget: [00:10:53] I mean, to be fair, I did have some demo videos and I did have an awful lot of, check out this open source project and this open source project and this open source project. They’re cool and they do this and they do that. But I do think that, and you’ve probably seen that, maybe you can speak to in your organizations, The rate of uptake or adoption of any given tool or any given open-source project has a lot to do with the decision-making of the people who are deciding whether or not to use it. It’s like, they’ll— it could be a technically excellent tool, and if there is no documentation and they haven’t said anything on their pull requests for 6 months, people are gonna be like, uh, I don’t think I trust the humans, even if their code looks okay. Like, I mean, what kind of experiences have you had, Adrian, in the workplace with, like, trying to decide which open source tool is the right one for you or anything like that?
Adrian: I think you hit the nail on the head there where if you’re looking at an open source tool and there’s pull requests that have been sitting around for months and are dead quiet and the last commit was 6 months ago and there’s no new releases, it definitely is a problem. And I think as Kuba said, the problem isn’t the code, it’s the people. If there’s no community around it, it’s not going to happen.
Bridget: [00:12:04] I mean, unless you look at the code and you’re— Dan’s kind of shaking his head and I’m wondering, are you thinking, well, maybe the code is great and you just jump on and become the project lead? It’s a lot to take on though, right? Well, yeah, there are always decisions.
Daniel: I think vitality of a project is an important and interesting thing to look at, but I don’t think it necessarily discounts whether a project should be used or not. There’s definitely projects and pieces of software that I’ve used and continue to use that haven’t had updates for 10 years because what they were designed to do, they still do properly now. So just because something hasn’t been updated in a few months, that doesn’t mean it can’t be used. Probably a better— unless it’s a horrible security updater problem.
Bridget: You know what I mean? I’ve run into that where they’re like, well, guess we’re pulling that out this week because there’s not going to be a patch for it. So now we have to refactor off of it. This week. Like, that’s always the risk, right?
Daniel: Yeah, absolutely. Thankfully, there’s more and more tooling around that that’s making it easier to know, and you build that into your pipelines or even just occasionally take a glance at the CVE list and really get a feel for the horrors that our industry has wrought.
Bridget: [00:13:15] I’m actually curious, Debbie, from your point of view, because obviously when tooling choices are being made at large enterprises that have you know, stakeholders who are looking at large stacks of rand or euro or dollars or whatever, I’m guessing they’re not okay with you throwing something into production that has, you know, one committer who hasn’t touched it in 3 years. I’m guessing. Do you have standards in general? You don’t have to go into specifics, but how do you decide, is an open-source project okay?
Devi: So, we actually have a principle that you can use open-source code. We do have very tight security and we’ve got to go through quite a few security checks and things like that before we put an open source— before we test an open source tool. The approach that we found worked for us was actually to take the community that uses the tool and start unpacking what are the problems that they are experiencing. And then we map out the entire value stream process that they actually go through. We then look at what are the issues that they’re dealing with within that value stream process. We get the team to prioritize what are the biggest issues that they start— that they have to deal with. And then we start looking at what are the tools that would actually solve their problems. We then put the tool into a proof of concept, whether it’s an open source tool or something we have to cash out money for. We then take the tool fully through the pilot or the proof of concept, and then we evaluate the outcomes against what we originally found were the problems that we wanted to solve. Where we actually do need timestamp measures, we actually literally stopwatch our developers with the times when we put the tool in, after we’ve gone through a learning cycle, we timestamp them again, and then we have reasonably scientific measures of efficiency gains. And we then do like a Harvey Ball 1, 2, 3, 4 rating, all of the principles and do an average. We sometimes test more than one tool with a team, or we take 2 different teams and run 2 tests in parallel, taking away the differentiating factors and moderating those aspects of it. And that’s how we test, that’s how we take a decision on our tool.
Adrian: [00:16:01] How long does that process generally take?
Devi: The process normally takes— we time block it. So, we try, if it’s an easy tool to use, we take about a 2-week process. We go into a team sprint at the start. We train them for a few days before. We take the tool into the sprint. If it’s a heavier investment, we run it for about a 6-week period. Our actual decision-making and sign-off process takes longer than our proof of concept takes because we’re a bank and people need to sign off everything, turns out.
Daniel: That’s really impressive. If I could just say, I was not expecting that level of an answer in terms of the clear steps and outlines and desired outcomes and really just the depth of analysis there. So congratulations, that’s quite impressive.
Adrian: [00:17:05] And in what I consider a relatively short space of time, 2 weeks to 6 weeks for all those things that you mentioned seems incredibly fast.
Devi: So what we do is we actually identify people in our organization that we know will actually use it and who does have a problem. We also found that if you actually just lock people up in a room for 4 hours, you can actually do a full process map.
Bridget: I like that. You mentioned also putting it in the sprint. Because if technical decision-making is something that you have to do in between your work, no, I mean, at least for the period of time where you are actively working on the decision, it has to be the work. For at least some people.
Devi: But it’s practical. So, it’s not a science experiment scenario. You have the real factors that people are dealing with in their sprint. That’s why it works putting it into their sprint as well.
Bridget: [00:18:12] It sounds like they take a great deal of care at Nedbank at least, and hopefully all the banks, in terms of making sure that the systems are secure and actually work. I mean, as a person who uses currency, I like this. This is great. Um, I’m interested actually, we talked a little bit about where you, you actually, um, Debbie, are coming in from Johannesburg. Uh, Adrian, you’re based here in Cape Town. Um, but when we were chatting last night at your lovely evening event, uh, you were mentioning that you, of course, you would love to help the Johannesburg team. And I was thinking Is that, I mean, it’s a 2-hour flight, but is it kind of, you know, just around the corner or is it like they are on the vast other side of the land and we barely have anything to do with them? Like, what do you see your involvement with the tech community in Johannesburg being like? Or are you like, mostly you’re just focused on Cape Town? I’m curious.
Adrian: I think my involvement up until now has been mostly Cape Town. It’s easy for me to get to. It’s people I know, it’s the communities I know. There’s potentially other communities outside of DevOps that I know, such as the Python community, that are very big here. Capetonians are also— Capetonians generally don’t like Johannesburg. We give it a bit of a rough time. They don’t have the ocean.
Bridget: [00:19:35] Is this like Melbourne versus other countries?
Devi: They only have a mountain and an ocean. We have everything else.
Cobus: And the wines?
Devi: We can buy you.
Adrian: So, getting over the fact that for some reason we don’t like Joburg, I think there’s definitely a growing DevOps community there. If there’s anything that we can do to help them create a DevOps Days and potentially any other community, we definitely should. I know the Python community, there was PyConZA, and it’s specifically PythonZA, not PythonCPT. And they have to have a meetup in Johannesburg and Cape Town to qualify under the Python Software Foundation. And so, I think we are exclusively focused on Cape Town, but since we’ve built these relationships with people such as Devi and a few of the other banks, it makes sense to at least share our experience and try and see if we can help. I don’t think we’re going to be running these conferences, but I also don’t think we should be running these conferences.
Bridget: [00:20:37] Exactly. I mean, Dan, you can attest to Who runs the conference in a given city?
Daniel: Not me. So the idea behind the DevOpsDays series of conferences is that they were meant to be localized, right? So wherever the conference is happening, that’s the people who should be running it, and that’s the people who should be attending it. Years ago, when there were very few individual conferences, there was more travel involved. For example, in 2013, when we did the Paris event for the first time, we had people from all over Europe because it was the only game in town. That wasn’t the goal.
Bridget: Or in the continent, as the case may be.
Daniel: Exactly. And that was never the goal. That was a necessary stepping stone. We reached a point now, I think we’re doing 75 events in 2019. And when I say we, I’m talking about the DevOpsDays community, right? It’s not like there’s a central committee that authorizes events to happen somewhere. These are homegrown grassroots initiative style things. And so, you know, despite my accent, I am French and I live in Paris and we do a Paris event. And if a team in Marseille wanted to do it, it would be important that I go, here are the mistakes we made, please learn from them. And then I back away and let the team there do it themselves.
Bridget: [00:21:58] I think that when DevOps Days Minneapolis started, That same year, DevOps Days started in Chicago, and Matty Stratton, who is the founder of Arrested DevOps, was running that one. And he said, the most useful thing is that Minneapolis was a few weeks or a month before us, so I could look at everything you did and then do everything that I liked from it, you know, and not do the things I didn’t like. I was like, I think that’s a really good guiding principle just in general. And I would say extending this past conferences just to our organizations in general. You know, Curtis and I both work at cloud providers, and we also— our cloud provider, you know, involvement in, say, the open-source space means that I’m hanging out at KubeCon, you know, EU with Arun Gupta and saying, you know, this is great. It’s so fun to hang out with people in this space where we know we’re— of course, we’re all working in this space at different organizations, but we’re also collaborating. On the same stuff.
Adrian: [00:23:00] I think the, the cross-pollination, um, between organizations is definitely important. As much as we’re talking now about helping Joburg get off the ground, um, once they run their conference, potentially we can learn from them and they can come and help us and potentially improve our conference, improving DevOps across all of South Africa and not just one or two areas.
Cobus: One thing I think would be very valuable to just quickly go is if Adrian take us through because you put a very nice process in place in GitLab with templates and things that we use to actually run our conference because that’s very nice advice for other people wanting to do it.
Bridget: Oh yeah, we can put a link in the show notes to that. You want to give us the TLDR?
Adrian: So, there’s nothing public, unfortunately. So, I was just thinking, we’re running a DevOps conference, can we use DevOps to run the conference? Can we automate the conference? Kubus and I also help run the Cape Town meetup group, And we found sometimes it’s a little bit tricky in, in, in a chat tool like Slack to follow different threads because we could be talking about different events at different times. Um, and so I’m a big fan of, well, I guess what happened is I took up a job in management and I had to start caring about project management. And so I started looking at ways that we could, um, use DevOps and automation, but also project management to run the meetup. So what we’ve got is private repositories in GitLab, one for the meetup and one for the conference. And inside there is, I guess, 2 things. There’s the knowledge base, which is in the form of a wiki, and then there’s the issues, which are actionable items. So for the meetup, we have a list of venues, a list of sponsors, a list of potential speakers. If anybody in our community has ever put up their hand saying, hey, I can speak, but contact me in 6 months’ time, we just put them on that list. We know who they are, we’ve got their contact details, and I could put them on the list, but Quibbles could call them up and ask them to speak, sharing that knowledge amongst each other. And then in the meetup context, we have one issue per month because we run one per month, and it’s got a template. And the template are the list of things you need to consider when running an event. And so for example, it says Have you got the venue? Have you got the time slot? Have you created a meetup.com page? Have you published that page? Have we got sponsors? Have we got all the things necessary to run the conference? Have we announced it on Twitter? Have we announced it on Twitter the day before, the week before, the month before, whatever our cadence may be? So, I think that the organizing of the meetup is easier with these issues. We’ve tried to apply a similar thing to the conference where We use milestones per conference, so we have a milestone for 2019. We already got 2020 milestones for ideas and thoughts for then. But additionally, we’ll create an individual item, an individual task per sponsor. If we think a sponsor might be interested, it’s labeled as a lead. We need to interact with the sponsors, see what they’re interested in, see which package they want to get, how, and get them to the point where they’re signed up. Once the sponsor’s signed up, we’ve effectively made them promises. They promise to give us money, we promise to give them a sponsorship package. Whatever level they pick might mean something different. And so, we have templates for each of those levels. A platinum sponsor gets a lot more than gold or silver. For example, they get to choose the Wi-Fi password at the event. And so, that issue has all those details, which means if it’s a checklist, we can go through and we can see, oh, we forgot to put this person’s logo on the email. Let’s just add it on the email and then check it, mark it as done. I feel like it’s still a work in progress, but to have the information categorized into individual tickets really helps. If I want to know the status of a particular sponsor, where they are in their sponsorship, I can find it. Or potentially a particular speaker, have we got their bio picture? Is it on the website? Is their abstract correct? Have we got their Twitter account? That sort of stuff.
Bridget: [00:26:59] Who knew that running a conference is actually a lot of work? I mean, Debbie, it’s so fun. It’s great. Yes.
Adrian: My goal is to automate it. I want to run a script that says, do Dev Upstairs 2020, and it should happen. I’ll share that script with you for Johannesburg when we get there.
Cobus: Then we integrate it with our voice control systems at home and it says, listen, have you contacted sponsor X today, please?
Bridget: And actually, of course, we were chatting about this and I was immediately saying, Adrian, excellent. I am going to deputize you to help rewrite some of the organizer guide to onboard new teams with all of the tasks that they do. Because, as it turns out, and I want to kind of get everyone’s thoughts about their experience at this conference so far before we say goodbye, but I will say that I go to fewer of these than I once did. And I will probably go to fewer still next year just because of changing job responsibilities But what I really appreciate is when I go to a local event and— I mean, by a local event, I mean not the one I run, but like one in a different city somewhere— and find out all of the things I had never thought of. And you don’t— I think sometimes the cynicism and world weariness of our industry and our world means that it’s hard to be surprised, just excited and positively surprised. And I’m just delighted and surprised when I come and I see all of the stuff that I’ve never tried that people are doing. It’s fantastic. So, um, I’ve really enjoyed that, and I’ll kind of go into more detail on that. But I would love to just, as we— as our outro, is that a word? Uh, I would love to hear from, um, everyone. And let’s just, uh, start with our speakers and then move on to our organizers, um, as to what are you going to take away from this event? Like what that has occurred here stuck in your mind is going to change you in some way or change your actions in some way or put something on your to-do list. Inga Clay Shafer likes to say that you haven’t actually learned until you’ve changed your behavior, until you’ve done something, not just experienced something or thought something. So let’s, let’s start with you, Dan. What are you taking away from this conference that you’re putting on a to-do to think about?
Daniel: [00:29:19] I would say probably the most, the single most interesting element I’m taking away from this is going to be Rory’s talk in general. Maybe you can put a link to it, or once the videos are posted, or give us the TL;DR. So Rory’s with Microsoft, and he is passionate about usability and about building things that are and can be be used by people all over the world regardless of their abilities, backgrounds, etc., etc. And it’s an area that I don’t know personally too much about, and it’s clearly an area that more people do need to know more about. And I have some personal experience, unfortunately, in this area. And I say unfortunate because, as it turns out, I didn’t know how to handle it before. So his talk has now inspired me to learn more and try to improve myself and try to improve the machines and the tooling around me in ways that are just better for humanity in general.
Bridget: [00:30:26] That’s awesome. I love it.
Devi: All right, Debbie. So for me, my big take-up is Dan’s that I must eat more vegetables. No, I think Dan’s talk really struck a chord with me. I truly believe that the success of any organization is based on the well-being of your people, and it really struck a chord with me around how you need to view this movement holistically. And the people are the key to the success of it, and their well-being is extremely important. It’s— work-life balance isn’t just a couple of words on a piece of paper, and Dan really touched on what are the important things that you need to remember for your team. So for me, it’s about making sure that the wellbeing of my people is really taken care of.
Bridget: [00:31:32] So true. Couldn’t have put it better myself. That was fantastic.
Adrian: Love it. Okay. Adrian. I would just like to comment on Dan’s response to Rory’s talk. I had heard that talk earlier this year at DevConf and it had the same effect on me. The takeaway for me was it’s time to start caring. And Rory’s talk made me realize that it’s incredibly easy for us to build accessible websites. And it’s no longer an excuse to have a website that’s inaccessible. And so, we should definitely care. So, I’m glad you have that takeaway. His talk isn’t necessarily a DevOps talk, but I’m glad it’s had an effect on people. And I think that we invited him to give that talk exactly for that reason. So, I’m glad it’s had an effect. In terms of my takeaway, I think this kind of comes out of conversations with Bridget, but I’ve got a list in front of me of 10 items that I think DevOps Days can do better. A lot of these items are things I plan on tackling myself, and some of them I don’t think I can tackle for various reasons. But my thinking is these things aren’t related to DevOps Days Cape Town. They’re related to something else. So, Joburg or bigger. And maybe what I should do is change my sights. Instead of looking at improving the Cape Town community, see if I have a way to improve the global DevOps community, which I feel like is a big task, but I’m hoping these 10 items that I’ve listed are the first step.
Bridget: [00:33:06] As someone who is the current titular lead of the Global DevOps Days community, I am very excited about your ideas and would like to subscribe to your newsletter. So, we will talk about that. That’ll be fantastic. All right, Corbis.
Cobus: For me, it was basically the interaction during the open spaces where you actually saw a lot of the more new people to software development and DevOps in general actually ask questions, and you can see there’s large gaps of not understanding bigger problems and things, and then seeing more experienced people help them. And it kind of makes me think that we really need to invest more effort in creating this community to make it easier to ask those questions. Because we’ve got so many people currently getting remote jobs and disappearing off the community scene completely that there’s a really big need for people to share what they know to help accelerate getting more people able to build. Just because, I mean, if you get that early in your career, it just completely skyrockets where you’re going to end up.
Bridget: Absolutely. Amazing place to leave this, which is exactly what I observed. I was here, you know, 4 years ago, and then, maybe it was 3 years ago, but 4 conferences ago anyway, and saw the spark of energy and excitement in this community that I was like, I bet they could have a really awesome DevOps Days. It’s very gratifying to come back and see something that, frankly, I had no control over, and also no input into for the most part. Like, I love the idea that we have this global community of people who, once they get some ideas and some encouragement, go forth and make their local communities awesome. Like, that’s the thing that makes me so excited about coming and seeing everything that you’re building here. And for example, I’ll give a concrete example. Not every DevOpsDays does the open space selection the way you did, but the way you did it, they jumped in and they were having discussions immediately. The pre-selection of ideas and then giving them a web interface they could add things to and then doing your own collating and sorting ahead of time, it’s a different style, but it’s not one that I’ve seen in exactly that format, and I think it worked really well, and you had great discussions. And so, that’s one of those things where I love the idea of seeing how everybody remixes and personalizes and makes relevant to their local community any kind of practices, whether they be industry practices or conference ideas or whatever. Anything that they get from those communications with the rest of the world and then make awesome in their local events. So that makes me super happy. Thank you so much for joining us today, panelists. It was a It was really fun. Head to arresteddevops.com/devopsdays-cape-town-2019 for this episode’s show notes. Visit arresteddevops.com/itunes and leave us a review in the iTunes Store if you want to help other people find the podcast. Asterisk, I have no idea how that works. We’re also apparently on Spotify and iHeartRadio if you’re into those systems too. That actually sounds like me, but that’s direct from text that Maddie wrote. Thanks so much to Quivus and Adrian and Duffy and Dan for joining us today. Thanks. It was great having us.
Daniel: [00:36:26] C’était un grand plaisir. Merci.
Cobus: Thank you for having us. It was my luck at Dunkin’.
Bridget: I’m Bridget at Bridget Krumhout. This has been a rest of DevApps, and remember, there’s always DevApps. The bananas dance.
