Lessons learned from building a community of Python users among Capital One's analysts

Lesson 1: It takes a village (or rather, a community of practitioners)

When it comes to actually moving the needle on Python adoption, it's important to put yourself in the shoes of someone trying to learn the language for the first time. For a new adopter, it might seem like a lot of work for unclear payoff and it might be particularly difficult to start the learning process on your own. We found that it really takes a village to support large-scale motivation and adoption and to overcome these hurdles.

Some of the major problems with starting a solo Python learning journey stem from a lack of support from peers or managers who may want to continue doing things "the way they've always been done." Overcoming that organizational inertia can be difficult without a critical mass of people on the journey with you. It's also harder to learn best practices (especially with the less technical skills) without a peer network to review and critique your work.

One approach the BDA team took to address these problems is to develop a support system for analysts outside of their immediate teams. By including Python training in the context of enterprise-wide programs, and especially cohort-based programs, we aimed to encourage cross-functional networking, collaboration, and resource sharing. This allows the networks to form organically from the ground up, while still having support from the highest levels of leadership.

Once a community of practice has formed, it's also important to make it easy to contribute to and extract value from that community. BDA leans on GitHub heavily to make projects editable by anyone and enable passive knowledge sharing through living documentation. On the flip side, we work hard on maximizing discoverability to allow people to take advantage of existing work and Capital One specific tooling.

Slack is just one example of a tool that serves this purpose well, because it addresses many of the pain points learners have.

On average, 23 questions are asked and answered on our #Python channel every week. With almost 2,000 associates in the channel, 820 have posted at least one message.

Lesson 2: You are going to be trouble-shooting people's system issues a lot

As large numbers of people started on their learning journeys we noticed the same kinds of early-stage problems over and over again. Issues like environment setup or installation issues are particularly trying because the solutions can be hard to generalize (different kinds of computers and starting environments) and therefore represent a fixed amount of time that has to be spent on each individual before they can become self sufficient.

Sometimes, the learners' resourcefulness will backfire when they proactively find and copy a solution to their problem that is suboptimal, which is then propagated to their network. Beginners can bork their systems in really creative ways, especially when copying and pasting solutions with no clear "right answer."

As much as possible, we try to support learners by taking setup issues off their plates. At first, BDA used one centralized location to aggregate all the setup best practices and provide that source of truth. However, the next level solution to this is to use technology to provision environments automatically and on-demand. Shared analytical environments give us the ability to spin up pre-made Linux sandboxes at will with pre-installed Python environments. Each particular course can come with its own instructions for how to set up the container, which automatically takes care of the GitHub interactions, data access, etc.

Lesson 3: Incentivize learning and adoption with real-world examples

Making the setup easier definitely helped more people to start the courses. But we wanted more than that: we wanted analysts not only to complete the courses, but also use what they learnt in their daily work. This is a challenging goal to achieve.

After our foundation courses had launched and been in use for a while we saw a pattern emerge: many students started the course but never finished. Some got distracted, others got stuck on a challenging exercise, and some just never clicked the "complete" button. The initial outcomes were similar to most MOOCs (massive open online courses), although our completion rates were higher. Additionally, some associates were excited about the courses but struggled to use Python in their daily work, especially under pressure from deadlines.

Our foundation courses taught some necessary basics, but there was still a gap in the knowledge, and lack of confidence when using it, that made the adoption harder. The solution to this problem was to focus on teaching analysts how to do their work with Python. We partnered with analysts to identify and scale some of the best practices and better understand their pain points. Doing that helped us to reimagine their workflow in Python, creating content with and for them, instead of just teaching abstract concepts. Based on this work, we now provide examples and code cookbooks relevant to their day-to-day work, which they can easily use and apply.

Another important aspect in succeeding in our goal was to align with senior leadership on the importance of training. It helped with finding the time and space for analysts to learn and to start applying new tools. Some leaders encouraged their teams to go through the training together, and even motivated Python adoption with prizes. We also created dashboards to provide visibility into the course completion rates of their organizations, because what can be measured can be improved. This helped to foster friendly competition and motivated leaders to better encourage their teams to complete the courses.

Lesson 4: Encourage cross-pollination of ideas

In the example above, we needed analysts' inputs to create tutorials that are relevant to them. It worked well, but it required some time and our input. But with hundreds of talented and creative analysts, we needed scalability, and we wanted to take the process of sharing best practices one step further.

We were facing issues that many big organizations face: analysts on different teams often solved similar problems over-and-over again. Furthermore, analyst teams could easily become siloed, reusing bad scripts and practices amongst themselves. While it was easy to explain how these scenarios happened, overcoming tribal knowledge, and the occasional non-standard practices it caused, was not.

Some analysts may prefer to start with GitHub search, but some good solutions are never discovered because the code was never committed (because the code was "not ready") or lives in a private repo.

And this problem is really tricky to solve - and, it's still a work in progress for us - but here are some approaches that worked.

• Instead of just advocating for best practices, codifying and championing them makes a difference. Cookie cutters and templates help to reduce the mental load of making choices when getting started.
• Providing gentle yet clear introduction of best practices helps analysts to write better code and eventually build it into a package - especially if it solves a common problem. For instance, if an analyst just learned the basics and has a bunch of hard-coded variables it means encouraging them to turn those magic numbers into variables. Then, helping them turn that code into functions, add docstrings and unittest. And finally, help them make it into a package that lives on GitHub so others can easily use it.
• Discovering what other teams are working on and discussing common challenges is also crucial to avoiding siloed-solutions. And while GitHub helps with discoverability, holding data-community conferences and monthly demos facilitates cross-pollination of ideas. So analysts can learn from one another, build on top of the existing projects, and avoid hitting the same problems over-and-over again.