Following up on Part I, where we discussed the different clubs that I like to use when running a Continuous Learning Program, we’ll now dive in to how we can pitch a Continuous Learning Program to Upper Management.

  1. Increased Inter-Team Communication
  2. Manufactured Serendipity
  3. Maintenance of Our Tools
  4. Builds Slack into Dev Process

Increased Inter-Team Communication⌗

One of the easiest benefits to explain is that as a result of these programs you will start to see increased inter-team communication. As organizations grows and the number of teams increase, knowledge silos start to become a real problem. They’re how you end up a myriad of different solutions for the same problem across your different teams. The good news is that a Continuous Learning program can help to alleviate knowledge silos! By getting members of different teams together at least once a week, and dicussing problems they’re currently solving or have solved through the frame of the current topic of discussion. Lunch and Learns are a great avenue for this, as teams can share solutions they’ve come across to a larger audience and potentially help other teams solve related problems. Code Dojo and The Refactory also play into this idea as well, for example if the problem being solved calls for recursion and engineer who is particularly skilled at recursion can share their knowledge on solving recursive problems which increases the skill of the other engineers present. This line of reasoning is going to lead us to our next topic: Manufactured Serendipity.

Manufactured Serendipity⌗

Let’s start by defining what we mean by “Manufactured Serendipity”: it is the idea that hard problems are not solved by construction, but rather through serendipity, so we should encourage serendipitous moments to occur as much as possible. This means that we want people from different teams/parts of the organization to have meaningful interactions to aid in problem-solving. It can be something as simple as what was dicussed in the previous section with a team sharing a solution to a problem they solved and another team utilizing that solution to save engineering time, to engineers across teams discussing problems and uncovering larger architectural problems that are more solvable on a larger scale. Google is famous for implementing areas for manufacturing serendipity such as the G-Bus and designing the cafés to nearly always have a line so that people can interact while waiting for coffee.

Maintenance of Our Tools⌗

Now that we’ve discussed some of the more communal benefits of a Continuous Learning program we’ll dive into how these programs affect the individual members. Just like how you wouldn’t say that physical tools are maintained just by working with them, we wouldn’t expect our tools as knowledge workers to be sufficiently maintained without specific work towards maintenance. Through clubs like Book Club and Video Club we’re able to increase the baseline skill of our engineers overall, and then through clubs like Code Dojo and The Refactory we’re able to engage in Deliberate Practice and perform the actual maintenance on our tools. Another good analogy to use here is that sports teams don’t test their skills in prod (the actual game) and neither should we, in fact the higher the stakes the more practice we should be engaging in.

Builds Slack into Dev Process⌗

This final point aims to solve one of the major points of pushback from Upper Management: won’t this slow down our development process. The short answer is no, it may seem like taking time out of our schedule durig the week would slow down the development process, but our goal is to actually make it more efficient. The straightforward reasoning for this is that by growing the skill of our engineers we are empowering them to make better decisions, and solve problems more efficiently.

Like most things, there’s more to it than the straightforward answer. When we factor in time for these clubs into our development schedule, we alleviate the time pressure on engineers. Experiments such as The Candle Problem have shown that when people operate under constraints they tend to exhibit less creative solutions and more of a fixed mindset with relation to the objects and problems present. They also help to keep people in the context of work while removing a bit of the time pressure so that their mind can slow down a bit. Generally downtime at home helps slow the mind down, but that means leaving the office and losing context of the problem that they’re currently working on. In addition, by solving other problems in the Code Dojo and The Refactory (and being exposed to them in Book Club/Video Club) we’re able to identify problems with similar unknowns to the problem we’re currently working on and can use that as a potential solution (as discussed by George Pólya in How to Solve It).

So that wraps things up! Hopefully this helps you to address any concerns that Upper Management might have around starting a Continuous Learning program at your company. Feel free to reach out to me via email with any questions/concerns or to let me know if this helped you start a Continuous Learning program.