John Contad is a Development Lead at MYOB and is a speaker at this year’s Agile Encore. The original article can be found here: https://medium.com/@jpcontad/databases-kindness-and-building-a-learning-culture-in-tech-93229e99b2dd.
Let me tell you about Gigi. Gigi is a friend of mine who’s a systems engineer. She had the problem of being bitingly unhappy. Unhappiness can be cumulative — small things here and there that pile up until you reach a certain tipping point. Lost and rudderless, she went to her manager to see if he had any advice — halfway expecting that he’ll say, “Hey, you should take a vacation”. Instead, the manager said, “You should try doing something for other people.”
Lacking any sort of life context outside of work, she decided to try and train other people in the organisation. Now, she hated it at first: she hated the jitters of standing in front of people, she hated the questioning looks, she hated the nagging doubt that she wasn’t in a position to be teaching anyone anything.
Then, she slowly grew to like it. Hell, she even loved it at times.
Then, she forgot she was unhappy.
Teaching as Data Transfer.
We’ll get back to that story shortly. For now, I’m going to be talking about the various experiments I’ve done with regards to the propagation of a teaching culture within my current company. Before we go any further, I’d like to outline the frame by which I try to attack this problem: “What if teaching is just data transfer?”
You have Idea X which exists within the head of Person A, which needs to be transferred to Person B – in a way that preserves as much of the content as possible.
Now, if we’re thinking of teaching as data transfer, we have to think about the two ways that data is transferred: synchronously and asynchronously. As various definitions exist, I’m going to use the one that best fits with my current agenda (ha!) — synchronous operations block both processes until the operation finishes, asynchronous ones do not. To put it in human terms, the distinction between the two is the “WAIT” — blocking the teacher until the teachee has understood the material.
“Do you understand it yet? If not, we’re going to go through it again.”
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. 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.
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 quickly.
Sounds good so far? Well, we have a couple of problems.
Single point of failure (SPOF). Easiest to identify would be the fact that the program suffers if I get hit by a bus. It also takes a long time to get a handle of the tempo of work.
Inconsistency. Let’s say that in a hypothetical quiz to test knowledge retention, 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.
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. Trainees who are mindful of time limits and other attendees’ desire to move on 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 generalising 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.
Take people who care, then empower them.
Gossip Protocols and Guilds.
The modern tech organisation often has an irregular shape; change happens quickly, and change is often distributed unevenly. How do you transfer data across a weird topology?
Enter gossip protocols: The easiest way to think of this is to think of a crowd of people sharing gossip. You send a message to person A (“Casey farts in the elevator!”), who then gossips it to the people they know (“Did you know that Casey farts in the elevator?”), who will then propagate it to their peers.
In very much the same way, some companies propagate knowledge through guilds — a slice of people across tribes and organisations who care about a specific topic, who meet a couple of times a month to trade knowledge. This knowledge then gets transferred to the attendees’ tribes.
Practically, this looks like the DevOps Guild I run for my current company — which has internal meetups (one hour twice a month) that hover from 50–100 people strong. We get multiple senders, arm domain experts with a platform, and get a nice coverage across the company.
There’s a couple of problems though:
Peer variance. The people who attend guild meetings will have different levels of topic comprehension. This puts us in a position where you want to be inclusive, but you don’t want to bore subject experts.
Still a broadcast. The format of a guild meeting is of someone delivering a presentation on something they care about. This still suffers from a similar lack of WAIT as in broadcast training .
At this point, the shoe is starting to drop that hey, we need more synchronicity.
Better Guilds?
And so we split the guild into working groups — essentially, smaller groups of people who care about a specific subject domain. It won’t matter if they’re experts at it or not; even people who were interested in learning about the subject matter were welcome.
These groups took the shape of several domains: Monitoring, VPCs, Searching, and so on. This paid dividends from a learning perspective, as it’s easier to be synchronous when you’re a much smaller group. Working groups had the luxury of stopping and waiting until everyone was on the same baseline.
Take people who care, then link them with peers.
Database Volumes and Mentorship.
Imagine a two-way relationship that allowed for the space for people to stop until information has been fully understood. Imagine that since it’s impossible to do it for a large amount of people, it took place instead between one teacher and one student. Now imagine if the teacher developed a relationship where they understood the student’s particular learning patterns and preferred teaching methods.
Sounds awesome, right? Sounds like mentorship.
Now a lot of companies will have programs in place to support mentorship, but very few will have it widespread. The approach after all, has a couple of issues:
Scaling. To be quite honest, the tech space still needs more mentors. Mentorship is time-expensive, and doesn’t allow for the same efficiency as a broadcast. Finding people who are willing to commit the time for regular catchups who only serve to better the life of one person is a bit of a task.
Initialisation. A fresh mentor who is a first-timer will take a lot of time to learn the ropes. Add the fact that there’s no one canonical approach to mentorship, and you end up doing it via trial and error.
But when it works, it works. So let’s make it better.
More Mentorships.
Cheap and lo-fi is my game, so I started by creating ticket lists for people who want to learn specific things — and appending names of the people who are interested in teaching. Think of it as like the telephone signs you see on the street. “Interested in a flatmate? TAKE ONE.”
This allowed for people to experience how great of an experience teaching is. This also meant that we had a fleet of people who can stop and wait until the teachee has successfully absorbed the information.
As always, there are good surprises. The people we taught started signing up to be teachers — and they actually fared better, as they still had the experience of being lost in the topic fresh in their minds. They were more likely to understand the best way to relay and transfer information without loss. They were more synchronous. They were more empathetic. We took people who cared, which created more people who cared.
Why the fuss?
We’ve talked about synchronicity, and how it enabled people to teach others better. But if you think about it, synchronicity is really just the space and capacity to interrogate and understand how the other person feels, what the other person needs right now.
A synonym of the word ‘kindness’ is considerate — the root word being ‘consider’, and I submit that that’s not an accident. Kindness is just the ability to empathise and think about what other people feel, and to understand what you can do for them. Nietzsche describes kindness as the most curative herb for the human soul.
Synchronicity is empathy. Empathy generates kindness. And kindness is restorative.
And Gigi, the sad engineer? She doesn’t exist. She’s me. And really, this whole thing has just been a journey of understanding how important being synchronous with other people really is. How it’s rejuvenating and restorative. How the fact that while I may not do it 99% of the time, the fact that the option exists makes all the difference.
There’s a lot of sad people in tech. There’s also a lot of people who are just starting out in this terrifying, messy space. I hereby submit the following proposal:
Let’s be deliberate in creating the Broadcasts, Gossip, and Synchronous Pairs that new people in organisations need.
Which really, is another way of saying that we should have the Teachers, Communities, and Friends that we needed when we were starting out.
Which, really, boils down quite easily: be the people we needed when we were younger.
Hear John Contad encore his AgileAus17 presentation at Agile Encore this year. Details available online: www.agileencore.com.