Episode 69: Fidelity’s Jimmy McNamara on Delivering Capabilities and Enabling People First

Brian Dawson: Hello, this is Brian Dawson hosting a special episode of DevOps Radio live from DevOps World, Jenkins World 2019 in Lisbon. I'm here with Jimmy McNamara from Fidelity Investments where he's I think officially a senior project manager, but as we discuss he has a focus on product management or acts as a product manager for developer team capabilities. I'm gonna ask him to introduce himself where he can correct me and tell me that I'm wrong. So, Jimmy, welcome. Thank you for coming. Can you go ahead and give yourself a proper introduction _____ _____ our listeners?

Jimmy McNamara: Yeah. So I'm a product manager in the application lifecycle management space, which is basically the tools that underpin capabilities developers use in Fidelity to produce software for the business. So my focus in this role is to identify – work with the business to understand what their needs are in terms of capabilities. You know, Fidelity as an organization has a really, really strong belief in IT being a real business enabler, and that's something that is invested in from the top down in terms of strategy. And my focus really is to enable the business, make sure that we're enabling developers across the organization with the best capabilities possible because we want them to be able to produce great software to make big differences in terms of products we produce.

Brian Dawson: Okay, and you hit – some of this we talked about before we went live, but you hit a couple of keywords in that segment there that I'd like to drill in on. First, capabilities really stands out to me, and as we share that, I have a particular opinion that it's important to discuss what we're doing in terms of developing required capabilities to achieve a _____ objective. Let me ask you, can you explain more – it sounded like – in our conversation like there's real – you know, you don't use capabilities sort of haphazardly. There's some real thought between using that word to designate.

Jimmy McNamara: Yeah. So what we do is we map out the key capabilities across the lifecycle of anything developed by developers in the organization, so really from planning, collaboration through to your source code management, your static code scanning, your continuous integration, continuous deployment, and artifact management. And really we see these as longstanding capabilities that we have to invest in and make sure that we provide the best-in-class features and tools to support the developers, which is – I mean, the net of it is that we do not want to get in the way of developers. We want to actually accelerate them and we want to make it very easy for those guys to develop great software and get it out there to enable the business.

Brian Dawson: So let me ask – to drill into that a little bit more, so if I understand correctly, you see capabilities as you kind of have – want to be the starting point, though not a permanent starting point of the software delivery lifecycle, application lifecycle, and an endpoint. To move software features from the start point to the end point, there are a set of capabilities that teams require. Is that –

Jimmy McNamara: Yeah, absolutely.

Brian Dawson: Okay.

Jimmy McNamara: And I'm responsible for a portion of that lifecycle, right? So there's other capabilities kind of to the left and to the right of that, and it's pretty much a circle, to be honest, in terms of –

Brian Dawson: Right, right, yeah.

Jimmy McNamara: Yeah, you know, in terms of DevOps –

Brian Dawson: Right, in terms of it's actually continuous _____ start and endpoint. Is it the start of the loop and the end of the loop or the restart of the loop? And _____ _____.

Jimmy McNamara: No, and I think for us as product managers in this space and any space the key to success is that you're delivering capabilities enabling people, and if you don't deliver, it should hurt somewhere. It should hurt the business because they're dependent on that. And that says to me that that product is really in touch with its business because it understands the needs, and if the needs aren't met there's an outcome not met.

Brian Dawson: So yeah, so let's talk – let's drill on that a little bit more, and this will play off of the other statement that you said later, and that's, look, at the end of the day we want to get out of the way of – this isn't exactly what you said, but the gist is we need to enable the developers and get out of the way. So would – the stack of order, when you talk about your connection to the business, is you own a set of capabilities in the application lifecycle. Your customer is the developer or the developers of the development teams, correct?

Jimmy McNamara: Yeah, absolutely.

Brian Dawson: Okay. And your drivers and your measures of success are how well can they do their job or how well do they address and drive the business's strategic goals? Is that fair?

Jimmy McNamara: Absolutely, and we kind of discuss it in a way. You know, we kind of _____ _____ partners. So I see the development organization as partners with us so that we – you know, when we have that discussion we have a partnership company, and it's very much – you know, Fidelity is quite a complex organization. There's a lot of different business units that operate in different ways. You know, they operate in those ways to support their business, and we – as product managers we face off, or I face off to all the business units and I have a dialogue with them. And, you know, it's about evolving the discussion from one of "I need this" to one of "Actually, here's my business requirements, right? And let's discuss that." And then it's my job and my team's job to have that dialogue across the organization and identify what's actually the best thing for the entire organization in terms of creating that capability? Because, you know, there's a lot of folks _____ dollars these days. We want to make sure that we, you know, get our best value for the dollar spent across the enterprise.

Brian Dawson: And is – so is there an either prescribed – is there a principle that your team has or Fidelity has on the tradeoff between finding a commonality across the team to reduce costs by identifying shared solutions versus allowing a team to choose the tool that best provides the capability they need for their tech stack, their workflow, et cetera? So I guess – and I'll phrase it another way. Is the default priority a reduced cost and unified tool, or is there some decision criteria that you use when you decide whether you're gonna support a one-off or a tool for a _____?

Jimmy McNamara: I mean, it comes down to the business value. So it's certainly not all about cost; it's all about value, right, the value for the organization. So the way we work with the businesses – we partner very strongly with them and we kind of see ourselves as an internal – 

Brian Dawson: A consultant or advisor?

Jimmy McNamara: A group that helps connect the businesses, right, so that as we see a need in a particular area, what model we've worked is we partner with the folks that have the specific need. Maybe they've identified the tool that they want, and we do – we draw that into the center. 

And we're pretty good in terms of making sure that if we bring a new tool or capability in, we know what it needs to be successful in this organization. We know, like, we're a pretty org. We know it needs to scale to, you know, 10,000-plus developers. We know it needs to be able to stretch and work in multiple different ways. And what we do is we have a good set of criteria that we partner with the business in, and then we draw in the other business groups and we work through kind of a review of the product or the tool and see – you know, the outcome we want is once we set up a new capability or a new tool, we already know how the organization wants to use it. We already know how we are going to monitor the system or the tool so that it provides what the organization needs. And that then leads to your best outcome, as in you bring something in, you make sure that it is a valid business need, you socialize that with the rest of the organization, you make sure it's kind of big enough and robust enough for the org, and then as you push it out, you push it out with the process in terms of how you want to use it already defined. And then, you know, folks can just use it, grab it. We'll wrap it in self-service, wrap it in automation. 

We've done a lot of work in the last number of years in terms of embracing DevOps, embracing external cloud, so you know, we've put a huge emphasis in the last few years in our teams to fully embrace ops. And I find if you hire smart, curious people and you give them an opportunity of complete ownership, you get really, really good outcomes. And for our area we've certainly seen improvements in terms of reliability of our systems. We've seen a happier team. We've seen organic skill set transformation within the team.

Brian Dawson: And this is within the application lifecycle tooling team, right?

Jimmy McNamara: Yeah. Absolutely, yeah. So we've – primarily we would've been a group of system engineers, you know, _____ systems –

Brian Dawson: Right, _____ _____ _____, yeah, _____ spin up a unit _____ and I'd throw some _____ scripts at it and maybe I'd install a Jenkins _____ _____ to make sure it's right, right? 

Jimmy McNamara: Absolutely, yeah. And then what we've done is – because we've kind of taken on DevOps ownership and we've also combined that with moving a lot of our workloads onto external cloud, what we're seeing is that – what we've seen is the team transform to, you know, software developers on the basis that they're actually spending most of their days coding Python and Java and now whereas previously they were logging onto systems. And, you know, by the fact that they're spending most of their time doing a certain task in terms of coding a certain language, we pretty much have a team of software developers now.

Brian Dawson: And their developing an understanding of how to service their partners, right, or their customers.

Jimmy McNamara: Exactly. And, you know, they're spending a lot of time developing. They're using the features of the external cloud to provide a _____ of automation around the tools and we're providing capabilities so that we can scale the stuff, you know, leverage the Elastic Compute. We're providing capabilities where we can look to actually observe the system and predict problems and intervene – intervene –

Brian Dawson: _____ _____ want to talk more about that, more – intervene before a problem.

Jimmy McNamara: Exactly, yeah, so there's – you know, there's limits and things like that. We can see and we can trigger recovery prior to the problem.

Brian Dawson: So let me – so I want to revisit that but I'm gonna pivot just a bit – well, not pivot. I want to kind of get to this philosophy of sort of standardization, connecting the different business units, and ask pretty poignantly do you foresee a time when you are able to just deploy a single commercial solution and a single set of tools for your entire organization? Is that realistic, practical?

Jimmy McNamara: Yeah, so I think the way I would look at that is you must meet the needs of the business. So it's about actually providing – you know, historically certainly in the area I manage, Fidelity operated where each of the business units owned their own tooling, right?

Brian Dawson: Right.

Jimmy McNamara: And that was done for a particular reason, you know, in the business, that it provided completely autonomy and ownership for those guys. So that business reason is still valid, right?

Brian Dawson: Okay, right.

Jimmy McNamara: So as part of a strategy to centralize ownership, you centralize the platforms but you must respect the needs of the business. So you have to provide capabilities so that there's a standard kind of core developer experience, but then you build in extensibility –

Brian Dawson: To meet their need and empower them –

Jimmy McNamara: Exactly, yeah. And, you know, you provide capabilities. And it depends on which capability you're talking about, but you provide levels of administration and access by the business units to do what they need, depending on what you want and what needs of the business. You know, you may go to a point where you kind of – teams manage their stuff themselves based on us kind of providing an image of something and _____ _____ _____.

Brian Dawson: Right, yes.

Jimmy McNamara: So it's really about, you know, enabling autonomous teams and enabling the business to go as fast as possible, and also –

Brian Dawson: Right, but with a level of shared visibility, shared governance, so compliance is critical and –

Jimmy McNamara: Yeah. Security compliance is absolutely huge. So everything we do is monitored and controlled and we provide strong layers of APIs to kind of meet those compliance and security needs. You know, it's a balance. It's that balance between providing the capabilities for the developers to go fast but do it in a safe and secure manner.

Brian Dawson: Right, right, right. Yeah, I love that. Yeah, you want to go fast – what you want to be able to do is innovate rapidly yet safely and securely or empower rapid innovation safely and securely.

Jimmy McNamara: Absolutely, and some of the benefits to having a central organization manage this is that you – that central organization can help join the dots across the organization, and we do a lot of work in terms of _____ _____ practice, skills, and working groups where we sit down and we share learnings. We share stuff we've done. And folks do a lot of work _____ their InnerSource capabilities and –

Brian Dawson: That's awesome. And I assume you don't always have to be – your team does not always have to be the experts in these things.

Jimmy McNamara: Absolutely not.

Brian Dawson: Part of it is facilitating a culture of knowledge sharing and collaboration, is that –

Jimmy McNamara: Yep, absolutely, yeah. And you know, some of what I talked about in my session in the DevOps World this week was about what we've done, and it's much work that the businesses have done in partnership with us as our own work. So it's – you know, at the end of the day it's about, you know, we're here to support the business to develop capabilities, so, you know, it's very important we –

Brian Dawson: So this is important and I'll just – so there's a couple of things. We probably said the word business in this interview more than last year I would have said in an entire month. I probably had conversations where we use the word business at this show this week, you know, more than maybe I did all of last year. I'm gonna want to click into that, but before we do I'm just gonna give you the roadmap. I'm curious about what scale are we talking. So you've talked about multiple teams, capabilities. In terms of quantifiable numbers, how many development teams, applications, and/or developers are you working with/

Jimmy McNamara: Yeah, so numbers-wise across our capabilities, you know, for _____ collaboration platforms we have up to 25,000 people using the system. We've got 11,000 developers –

Brian Dawson: Wow.

Jimmy McNamara: Who check into our source code management systems on a monthly basis. We've 150,000 active builds in our CI/CD platforms. 

Brian Dawson: Wow.

Jimmy McNamara: We've eight million artifacts under our artifact management system. So it's pretty large.

Brian Dawson: That's pretty – yeah, that's impressive, just a little bit.

Jimmy McNamara: Yeah. So again, that's why as we bring in new capabilities and tools, you know, it's really important that those tools have proven scalability, reliability, because people within Fidelity and developers have high expectations in terms of the platforms they use. And IT is really key to Fidelity, so downtime and things like that are not tolerated. 

Brian Dawson: Right. So risks with unstable, unproven tools are not something Fidelity can afford to take.

Jimmy McNamara: Yeah. And so what we've done is we've done, you know, _____ team – _____ _____ capabilities and tools is we work with them, we bring them in, we evaluate them, and then we provide good feedback so that once certain things are _____ _____ – 

Brian Dawson: Then now that'll be _____ gate. Now you can sort of _____ _____.

Jimmy McNamara: Yeah, and so we have, you know, dry vendor roadmaps, you know, through that process. 

Brian Dawson: And so I'd like to ask – you mentioned your talk and we'll get on the _____ to that path in business, but you talked about managing a DevSecOps culture at scale in a multicloud environment. What are some key takeaways? I know that not all of our listeners are probably not here; they didn't get to see the talk. Can you share with us the premise of your talk and some of the key takeaways?

Jimmy McNamara: Yeah, absolutely. So I suppose the talk itself had a few threads going through it. One of them was that we as a team, as a group within enterprise cloud computing took decisions to embrace DevSecOps, right, as teams, and take complete ownership of operations. You know, I think the kind of way I think about this is that there's no better place to know your code than a production environment, right?

Brian Dawson: Right.

Jimmy McNamara: So – and if you have smart _____ people, they're embrace those challenges. So what we did a number of years ago was we took on that ownership, right? We also made decisions in terms of moving our workload to cloud, and as part of that journey the team embraced the challenge and really kind of transformed themselves through the work they did and achieved from those systems engineers to software developers and engineers, which actually are more valuable to the broader organization, right? 

Brian Dawson: Right, right.

Jimmy McNamara: So that happened kind of at a team level. And then at a kind of system and outcome level, we moved our workload to external cloud which provides that elastic compute so that, given the kind of large volumes of people who use our systems, we're able to scale up and scale down as we want to meet that need, right? So that _____ that actually that – as a product manager, once we kind of got to that place where our platforms were more reliable, and we spend a lot of focus on observability, ensuring that we understand how people consume our platforms and making sure that, as they consume it, they were meeting the kind of service levels that _____ want. 

Brian Dawson: Right.

Jimmy McNamara: And what it meant from a kind of strategy and roadmaps perspective is that once we kind of nailed the basics, is what I kind of termed it in the presentation, you know, the conversation with our partners changed from one of, "Okay, well, we don't need to talk about reliability of these platforms" –

Brian Dawson: It's assumed, you're saying, right?

Jimmy McNamara: It's assumed, and actually we can spend more investment in terms of just adding more feature functions to the platforms. So we can talk about, well, what are the key kind of features that developers require? And what makes sense in terms of both to invest in those to help enable developers have a less-frictionless experience so they can go faster?

Brian Dawson: _____ so that – so it's really interesting – you're doing a good job of setting me up for segues so you're making this easier, but – is – what I just heard described with kind of your order of operations is almost the reverse of what we're seeing with I think more grassroots innovation. And I think that that ordering is important. So what you tend to see is individual contributors decide, "I need X capability." They go out and they find something that provides it. They solve their immediate, short-term need. And only after you've seen the successes do you then start to worry about how do I scale it, how does it run. And oftentimes I've experienced that lack of foresight about if this thing works, this capability works, where do we need to be able to take it has resulted in, you know, expensive _____ investment where people haven't thought ahead and they have a failure, whereas it sounds like what you've done is – part of your approach is, "Let's ensure that we have a tool that meets our shared business requirements in terms of scalability, reliability, and once we've built that, now we can start to talk about the Chrome, and" – or maybe it's not Chrome, right? It's not extraneous capabilities, but now let's start to focus on building out capabilities. So did I get that right, that –

Jimmy McNamara: Yeah, I think it was more about, you know, you've a finite amount of engineering capacity to go after your roadmap, and if you're spending kind of a lot of energy and capacity in terms of keeping things _____ reliability, you know, that reduces your ability to focus on those feature functions. And I suppose the journey we've taken has allowed us to automate ourselves out of that type of work.

Brian Dawson: Interesting.

Jimmy McNamara: And then we can really focus on the stuff we really kind of – the really high-value things. You know, as part of the journey as well we've focused on culture. We've focused on projecting out the different way we're working and sharing that information –

Brian Dawson: Embodying and modeling –

Jimmy McNamara: Absolutely, yeah. So, you know, we've kind of worked with the team in terms of what are our principles in terms of teams? And we've put that up in the area _____ in to kind of ensure that we as a team have thought about that and we're projecting that information out.

Brian Dawson: I like that. I love that, and I love the emphasis on at the end of the day your charter is, you know, by title application lifecycle tooling, but you're acknowledging process practice and culture are key things that your team needs to implement and model –

Jimmy McNamara: Absolutely, you know. And, you know, great culture is going to help us get there, and it's just about making sure that we can share that information across the organization.

Brian Dawson: Awesome, awesome, love it. So with that, right, we talked about your approach, and it's funny. It aligns to – I hear a lot of what you're talking about, and I think it's by design – it's being applied and implemented with your team, fits very much with how we talk about best practices for your application delivery teams, right? And so you are one of the people you're servicing. And part of that – it sounds like you've had to give special consideration and think ahead as to, you know, what does it look like to build the roadmap with a strong focus on data for those insights, a focus on external clouds? And it sounds like you also have a multicloud component, and integrating various ALM capabilities. So my question for you is what advice would you have for other people that are where you were on this journey a couple years ago? How should they be going about building a roadmap _____ _____?

Jimmy McNamara: Yeah, so I think it's a number of things. So first of all, you know, one of the challenges is developing a really strong partnership with your business _____ to help to really understand what the needs are. So, you know, in some ways I'm a consumer of the services of providers, right? Because we're a development team ourselves, so you've got to eat your own _____ _____, right? So I think one key thing is you absolutely need a really, really strong partnership with your business. You need to collaborate with them and really understand what the business needs are. And then I think, you know, as you focus on your roadmap, you focus on capabilities. Capabilities are longstanding things that will exist as I'm gone, as someone else who takes over for me are gone, right? And it's all about investing and moving the needle to continuously improve the capabilities. So that's _____ more from a project out and work with your partners.

And then you've got the other side of things, which is, you know, building a great team, right, and giving – and actually a lot of that is about hiring really good people. And that's about, you know, make sure that you hire people who _____ a passion for technology, who are critical thinkers. You know, so when suggestions are thrown out, they have a point of view –

Brian Dawson: and they're engaged. Well, let me ask – and please don't lose your track 'cause I want to pick back up on this question about advice for building the roadmap. But let's dig into that. Do you have any tips for how you ensure you hire really intelligent, passion people? Is there a particular question, a sign, a signal?

Jimmy McNamara: Yeah, so I think as part of, you know, your process and your dialogue with people you can question in terms of their appetite to understand technology outside of work, you know, their kind of ability to kind of use _____ or follow tech logs, things like that, and you know, understand that they – have they got a real kind of passion and a point of view –

Brian Dawson: to measure their external presence, right, to see if they're

Jimmy McNamara: Yeah – no, that's obviously – that's growing and that's – you know, and these are all datapoints. But to me it's about, well, you want someone who's curious, right? You want someone who's inquisitive, and you want somebody also that's got a point of view, because we've talked about diversity, right, as part of – one of the _____. And, you know, our organization places a huge amount of focus on diversity –

Brian Dawson: On diversity or – yeah.

Jimmy McNamara: Absolutely. And you know, we do things like – we've got a Fidelity Cures program that goes into schools, focuses on STEM and focuses on getting girls to – focusing on those subjects –

Brian Dawson: Attracting passionate – and yeah, so that's really interesting, right? Corporate culture having an influence on who you hire, and a thread that I see there – tell me if I'm wrong – is, you know, we support passion projects, support diversity, which are the type of things that attract people that value those things.

Jimmy McNamara: Absolutely, and – yeah, at the end of the day diversity – so we work in IT, right? In IT you've got a lot hard problems to solve, and if you have a more diverse team that are looking at that problem, you are gonna have more points of view in terms of, you know, potential to solve the problem, and if you've got more points of view, you're gonna have better outcomes in terms of your solution.

Brian Dawson: I love that – yeah, yeah.

Jimmy McNamara: So that's a large focus for us _____ _____. And I think culture – I was kind of talking about, you know –

Brian Dawson: oh, yeah, go ahead.

Jimmy McNamara: So there's a business side of our partnership _____, and then there's a culture and kind of creating that culture within the team. And it's – you know, it's making sure you hire the really curious folks that have a real passion for technology, and it's about the leadership within our organization and within our teams to lead and provide – you know, to basically kind of harness the passion of the team members.

Brian Dawson: Right, right, to help capture that power and aggressive –

Jimmy McNamara: Absolutely, and you know, create – provide opportunities, because, you know, if you've got the right people, they'll do the right things.

Brian Dawson: That's – and if you don't have the right people, you can have all the process and all the money in the world, and nothing's gonna happen. I love that.

Jimmy McNamara: Absolutely.

Brian Dawson: So I'm gonna bring up the business and I'm gonna approach this this way. I'm gonna put up hypotheses out there that – and I want to get your thoughts on it – that we can and we need to get good within our software app dev teams and software function at delivering better software faster, i.e., we can deliver iteratively, more reliably, with higher quality, and empower innovation, right? We measure that. We achieve that by agile continuous integration, continuous delivery, or this thing we call DevOps. And we're now finding out that we can deploy more frequently with less lead time, with lower change failure rates, faster recovery time, right? Agreed?

Jimmy McNamara: Mm-hmm, mm-hmm.

Brian Dawson: But I believe that that's localized optimization that does not address the whole picture. So our application team can deploy a thousand times a day, but if they're not working with the business to ensure they're developing the right thing, they're driving impact, and they're actually – you know, _____ _____ _____ actually moving customers, then we're delivering more, we're delivering faster, but we're not ensured that we're delivering value and moving the needle on the business. Thoughts on that? Do you agree?

Jimmy McNamara: Absolutely. No, it's – you know, it's great being athletic, but if you're running fast but without actually winning things –

Brian Dawson: Right, or running in the wrong direction? [Laughter]

Jimmy McNamara: Absolutely, that's even worse, yeah. So yeah, absolutely. So I think agility and scale of agile and drawing the business into, you know, the development world is key, and that's something that Fidelity's very, very focused on. You know, and I kind of said earlier, right, that if you are a project manager and you are developing and delivering a roadmap, if you don't _____ then the business should suffer, right? That would represent a strong roadmap. So I think absolutely it is critical to – you know, for us as a development organization to get really athletic and really good and really quick, but we also have to be fully linked in with the business to ensure – and you know, the business is part of our world, _____ _____.

Brian Dawson: It's kind of like a baton, right – a relay race. You guys have to be really fit to carry your part, but at some point you've got to get the baton from somebody and hand it off to somebody, right?

Jimmy McNamara: Yeah, so it's like a production line. You need to get really quick at running the production line, but we'd better be producing the right stuff as well.

Brian Dawson: Yes, I love it. Okay. And it's interesting to hear – and we want _____ _____ _____ encouraged to hear that that is a point of view that Fidelity has, and it sounds like you guys are implementing it. So as we get ready to head towards the end here, I'm gonna give you – I have standard questions that I ask during these interviews. I'm gonna give you the choice as to which one you want to answer, okay? So either you can tell me about a DevOops, not DevOps, but a DevOops situation, in which there was a failure, maybe embarrassing, maybe very public, but also very informative that you learned from and our users could learn from. So chew on that for a second, or the other – and I would challenge you to be different in this – is share an important text or reading, book that has helped you navigate your path here at Fidelity and your career overall that our listeners should read. And when I say be different, we've already had multiple Accelerate: State of DevOps reports mentioned, multiple Phoenix projects. It does not have to be a technical manual. So which one would you like to answer?

Jimmy McNamara: They're good questions. I think probably maybe talk about some stuff that has gone wrong.

Brian Dawson: Okay, I love it. I love it. Okay. I didn't want to put you on the spot if you weren't ready for it, but yeah, so –

Jimmy McNamara: I'll probably be general because, you know, it's tons of stuff – 

Brian Dawson: Okay. [Laughter]

Jimmy McNamara: You know, if you are working in IT, stuff goes wrong, right? It's an extremely temporal industry, right? Stuff changes all the time. So even in my current role, you know, when I look back at maybe a number of years ago when our systems weren't as reliable as they should have been, I think what helps to develop a really strong culture within a team is when you go to hard places with people that you actually work with, right?

Brian Dawson: Interesting. Okay.

Jimmy McNamara: So I think that – you know, experiencing situations when you are working late at night, early into the morning to fix systems – that you're on a phone call, I think, right, for me personally that has helped me to be really attuned to identifying kind of really effective people, because if you've gone through those situations, you know, there's a certain level of understanding you have in terms of the reality of managing large platforms and systems. And it's something that I think I've leveraged as part of my interviewing folks, probably asking similar questions to –

Brian Dawson: _____ _____ this, right.

Jimmy McNamara: That you've asked me there. But it's – you know, just – I think people have – it's a great thing for people to kind of done the hard _____, because what it means is once you can identify opportunities like enabling DevOps, right, in an organization, you jump on it and you run, because you –

Brian Dawson: Ah, that's interesting. That's interesting. So that's an interesting lesson on – to kind of paraphrase, is failures, right, just generally we have them. A system fails. We're all on – I've spent many of these, you know, _____ at 12:00 in the afternoon and probably at about 3:00 a.m. we've figured out what the heck is going on and we've fixed it, right?

Jimmy McNamara: Yeah.

Brian Dawson: And you're saying those failures are an opportunity to build relationships and culture, and people that have experienced those failures are gonna have more of an understanding and the benefits, _____ practices bring to overcome them. Is that –

Jimmy McNamara: Yeah, absolutely, because they've gone through the full lifecycle. They've gotten there. They've fully understood operations in its almost painful sense, right? And it just means – I think the type of – if you've gone through those experiences and you were building software, right, you're gonna make sure to spend that little bit of extra time to make sure that, you know, you've really built the best software possible, because – and especially if you're in a full DevOps mode. You know, then you've got full ownership, so then – you know, and you know that once that code hits your production environment, everything _____ is gonna be found out, especially when you're dealing with a large scale.

Brian Dawson: Yeah, yeah. No, that's – yeah, I think – I can think of so many analogies. I know we start to get limited for time, but yeah, I can really appreciate that. And a team starts to get stronger, one, when you embrace – I'll throw in our pursuit is not perfection, right? Our pursuit is improvement. Our pursuit is our ability to respond to failure almost _____ _____ how many times you get knocked – or that you get knocked down, it's how fast you get up or how many times you get up. And so I really do love the idea. It's just let's not expect perfection. Let's continuously try to improve, let's learn, and let's work together to improve. And let's get passionate, knowledgeable people that can help with that.

Jimmy McNamara: Yeah, absolutely, yeah. And you find in that situation the people who will go the extra mile for each other, when I've gone through those experiences.

Brian Dawson: Love it, love it. And it's getting to be cliché but I mean it every time. I wish we had more time to dig in and unwrap that. Hopefully we're gonna have some conversations offline sometime. You know, in closing – thank you for sharing that, by the way, but in closing I'd like to ask do you have any final thoughts, advice for our listeners, any thoughts or comments to share about the overall DevOps experience, DevOps world, Jenkins world, what have you? What are your thoughts?

Jimmy McNamara: Yeah, I just think to work in IT, the computer industry at the moment is fantastic. I think we're kind of in a golden age of the stuff that's going on, the level of innovation, the level of change. It's fantastic, so it's just – it's great to be involved in it and it's great to kind of take on things like DevOps and drive it, you know, to kind of deliver better outcomes for folks. But it's just an exciting time in the industry.

Brian Dawson: Awesome, yeah, I heard that. I agree, exciting time to be a software developer. Things are looking up. Well, Jimmy, thank you for your time. Thank you for your thoughts. Thank you for sharing your lessons and insights, and hopefully you'll enjoy the rest of the conference here.

Jimmy McNamara: Yeah, will do. Thank you very, very much.