 Hello, everybody. My name is Frank Wu, and this is my lightning talk around contributing to a community at a bank. Does it help or hurt your career? So first, a little bit about myself. What I'm about to say is my personal opinion. It does not reflect my employer who is Red Hat. And I am based in New York City, focusing on supporting large financial services and institutions. But I have a history of working with various open source technologies, including open source databases, as well as in the data center infrastructure space. Before we began about voting a career at a bank, I thought it's important to understand the history of banking and really the scale of how technology has developed at the banks. One of the stories that's resonated with me was when I had a customer tell me how Facebook in the early days and all the other quote-unquote web scale companies made the trek from California to New York City to really look to understand how the banks operated at scale. Because this is something that a lot of folks know, most likely attending, but the banks have been operating at scale for decades, employing tens of thousands of developers, running code across hundreds of thousands of servers. The interesting thing about how the banks have operated was from a historical perspective, a lot of this was done mostly on proprietary and homegrown tooling. And to build a career within the bank, a lot of times the path to building a path to a distinguished engineer was to contribute custom code or maintain part of the technology that enabled the bank. To advance one's career, it wasn't necessarily about sharing or collaborating with other groups, but rather controlling a particular technology or contributing to a particular homegrown technology that enabled the bank to do their business activities. So what's changed? Well, this is the open source strategy forum. So I think it comes to no surprise to everybody that the growth of open source has risen dramatically. Not only has the rise of open source been around a community open source, but also enterprise open source and the decline of proprietary software. The growth of open source has touched all parts of the stack. It's no longer just the operating system where Linux is fairly pervasive, but it's touched the database world, the analytics space, as well as security and cloud management. Another thing that has changed fundamentally compared to decades before has been the rise of public clouds. Whereas previous IT workers were always working in a walled garden, so to speak, operating in the bank's homegrown kind of enclosed environment. Today, that bank employee on the weekend may have access to on-demand computing resources and a plethora of tools and technologies and think to himself or herself, hey, why can't I use this tool or technology at my day job? It works pretty well. So thinking about the framework of growing one's career, the way to think about building an internal community at a bank is really around the idea of bringing on board a new technology to the bank, typically a open source technology that's not necessarily supported and not part of the corporate standards. And you really have to look at the trade-offs on the left side and the right side. On the left side, when you bring on board a new technology, you really have to consider does this technology solve an immediate business problem? Does my ED or MD have a particular deliverable and bring on board this new technology, close that gap that exists today? And that gap may be budgetary and may be a function of the product. Are there others within the bank that have the same problem where this is something that could be repeated? And moreover, are there others in the industry in the financial services industry also looking at evaluating these new choices with the growth of these different open source options? On the other side of the trade-off, you really have to wonder, does it really make sense to bring in yet another technology or choice in all the options that exist today just given the significant level of effort to integrate into existing systems? And really, this is an important question I pose to engineers is, is this about a technology solving a business problem or is it about politics and religions in the sense that you may not like the corporate standard because it's based on a particular coding language such as Java, for example. And you really like Haskell or Erlang, and that's why you want a database built around those programming languages. That's not really valid enough. So thinking how building a internal community around a new open source technology that you're bringing to your company, you really have to think and understand who you're interacting with and how you're solving problems. In a typical traditional hierarchy of the bank, you have the EDs, DMDs, SVP, CTOs and so on. And you'll see that as the higher up you go within the hierarchy, the longer the time horizon is. At the lower level, someone may care that this technology can solve a particular problem, but at the higher up, that's where this technology becomes more strategic and building an internal community may actually benefit the company in ways that you may not anticipate. At the highest levels, what's really important to the bank is around talent, around attracting and retaining and managing people. And understanding how you keep the top 20% performers engaged and perhaps stimulated, if you build a community around the latest machine learning or artificial intelligence tooling, that may really benefit the top 20% performers and have them stay at the bank as opposed to go to Facebook or Google to work. On the other side of the coin, there's also a question around how do you leverage and optimize the bottom 80%, right? The 80% may not necessarily be the most rockstar programmer, but they can contribute a little bit to the overall knowledge of the bank into the community and there's 10,000 of them and they all contribute a little bit. That makes a significant shift for the bank. So let's talk about a real-world story. This presentation isn't about Ansible Automation, but the example is. One common problem that banks often have is around integrating various domain-specific tooling and specifically around use cases such as disaster recovery or application resiliency, right? Oftentimes, the technology is not the problem. The problem is around the manual coordination and handover between the two different groups because there's a dependency on the database side or perhaps a dependency on the networking side, right? Given the size and scale that banks operate, it's simply untenable for everyone to be consolidated under one big DevOps group or cloud groups. So it's really around how can I coordinate and orchestrate the different workflows across these different disparate groups and technologies. For those who are not familiar, Ansible Automation is a great use case and tool for this type of problem. Ansible is probably one of the most popular automation frameworks and language in the world. It's designed to be very simple based on yet in their market language where anybody, if they're a Linux admin, an application owner, a firewall administrator, can understand the automation syntax based on YAML and it's agentless, which means it's a very simple and lightweight technology, enabling the stitching of all these disparate technologies. So at Web Bank, there was once a Java developer that hated waiting for his JVM to restart and he knew from a technical perspective, it did not take five to six hours for that JVM to restart, but he had to wait five to six hours in order to get access for that JVM to restart. And he decided to bring on board a new technology, one that is based on open source at the time called Ansible. With the support of a managing director, he was able to help integrating parts of this technology to their homegrown system and start a little community. I really build a coalition of various stakeholders with their own use cases, ranging from networking to application owners. Today, that internal community at the bank has grown by leaps and bounds and there's a massive global community of 5,000 users from India, Ohio, the US, the UK where they're all writing code and reusing that code and sharing it across the different lines of businesses and groups. Moreover, there's a great internal community chat room based on symphony or other chat tools where if a new user has questions around the technology, the product owner of the bank doesn't actually have to explain what the technology is, but rather other users of that service that are part of the community can help answer that Q&A. So going back to the question, does building an internal community at the bank benefit your own personal career or not? This is a slide that really shows if it does and whether or not you can reach that inflection point. At the far left side at level one, you'll see the effort to make change is very, very high and the internal community benefits are low. And this is a challenging time because you may be an individual contributor that's passionate about technology that you know will solve a lot of problems at the bank, but you have your day job, you have your deliverables and it's very hard to affect change as an individual and the effort level is very high. As you start progressing forward to the right, you see as you build a community, you start standardizing how that technology is brought in and as new users want to use that technology, you can explain, hey, this is how I work for security to get this done. This is how I work with compliance and the inflection point is really around level three, and where a community is self-sustaining. This is where you as an individual don't have to do all the care and feeding but rather the community itself is self-sustaining and can help onboard new users based on their own individual use cases. Level four is really where it becomes institutionalized. It's where the CIO and the CTO look down and they see this grassroots coalition of stakeholders all using this new technology to solve real business problems and they formally institutionalize it across the enterprise and across various teams. And at the far right side is really where you see this idea of a federated community-driven development where folks at the grassroots level are rapidly prototyping, experimenting new ways to use that technology and if it's successful, they reshare and use that knowledge across different lines of groups and businesses at the bank as opposed to a top-down approach where you have a committee mandating to you how to use that technology. Last thought I would like to close on is oftentimes when you meet with individuals they often tell you their job title. They say, I'm an engineer, I'm an architect, I'm an assist admin. But when you think about it, a lot of times what you do from a job title perspective is only 10% of what you do. And 90% of what you really do is work with people. And if you're going to try to optimize something that helps improve your life or perhaps the business of the company you work for, why not focus on the 90%? And that 90% is really around building communities. Thank you so much.