Broadcasts, and Fan-out Training.

At some point in a company’s lifespan, they will start to think of teaching as a critical component of the system of work. Enable developers, make cheaper mistakes faster, all that fancy jazz. And when a company thinks of how to teach other engineers, they will frequently lean into the model that people are most familiar with: broadcasts.

Think a pub-sub model, or perhaps Amazon SNS — you have a standardized message, being fanned out to several subscribers and endpoints. When you publish a message to the topic, the subscribers then receive the message in a way that is specific to the protocol — HTTP endpoints get POST-ed to, email addresses get it via SMTP.

In very much the same way, a company will create a syllabus of content that is easily copied and reproduced, and that content is then broadcasted in batches. In my current company, this is done via an internal AWS training program — we take 25–30 developers every quarter, then sit with them for three days, going over various AWS products. Every now and then we’ll need to uplift the content, but this is a relatively cheap process we can deploy and scale quick.

Sounds good so far? Well, we have a couple of problems.

SPOF. Easiest to identify would be the fact that the program suffers if I get hit by a bus. Having inherited the program from (awesomer, and better) other people, it personally took me a long time before I got a handle of the tempo of work. Add the fact that teaching requires extensive knowledge of the material I had to deliver, which means I had to have the comprehensive lexical knowledge of three days worth of teaching material.

Inconsistency. Let’s say we had a hypothetical quiz to test knowledge retention at the end of the program. And because we’re all fantastic, smart people, let’s say everyone got 90% across the board (awesome!). My main point of interest is in the 10% that did not get retained — specifically, the fact that this will be different across everyone. Now this is where the analog of SNS falls apart: SNS tailors message delivery according to each individual recipient protocol, where individual lecturers cannot do that.

Anti-synchronicity. In-place lectures are frequently referred to as synchronous training — but for this specific case, I’d like to present a counterpoint: there is an immense social pressure that comes with not wanting to be the person who drags the class down. Synchronous processes block until the operation is finished. A trainee who is mindful of the fact that A.) The training program has a time limit, and B.) Other attendees may want to get to the next set of material will not raise their hands to say, “Hey, I don’t get this yet.”

WAIT calls don’t get issued. The class continues on.

Better Broadcasts.

Let’s focus on the first problem as the last two are endemic to the broadcast format. At least I can fix that.

The first problem was addressed by opening up the floor to people who held a particular interest in the subject matter. Tech geeks are often passionate about very specific things, and I’m a big fan of letting people work on things they care about. This meant that security geeks could raise their hands to talk about VPCs and KMS, and automation nerds could teach Cloudformation.

Now this worked fantastically, because people who care about things passionately are A.) More likely to own it, B.) More likely to improve the quality of their space, and C.) Way more likely to put effort into making other people understand why they care about the specific subject matter.

The last part is particularly important, because it had the beautiful side effect of generalizing the training modules. People are usually more passionate about knowledge domains and practices than they are about specific products. And if you want to make someone understand your passion, you do it by explaining why you care about the topic within a bigger context.

In practical terms, this meant that VPC modules turned into a broader networking piece. Instead of talking about KMS, we talked about asymmetric/symmetric cryptography. Instead of talking about Cloudformation, we started talking about the principles of automation and why infrastructure as code is important.

Take people who care, then empower them.