Many technical leaders know how to scale what they build,
but many don't know how to scale good practices in a team.
4 lessons to teach your team at scale, from the Samman method:
1️⃣ Active over Passive
Understanding new concepts require elaboration.
Provide a space for others to elaborate either by talking or writing, and less by listening or reading.
Rather than getting others to sit in a 1-hour talk to learn new concepts, facilitate a 1-hour session where they can sit down and actively elaborate.
The Samman method calls this the learning hour.
You can still give a talk, but cap it to 10 minutes.
When elaboration is done as a group exercise, the team will benefit from listening to each other's elaboration attempts.
Listening to diverse articulation strengthens the connection to new concepts better.
2️⃣ Concrete over Concept
We build connections in our heads when we put new concepts into practice.
Provide an easy medium for others to practice so that they can start to build the connection.
Create small exercises for others to experiment on, and do this as a large part of the learning hour.
If the concept you're trying to teach is about coding, prepare a small kata where others can apply the concept.
This kata can be borrowed, or created from your codebase.
Group people to experiment and learn together during learning hours.
Not only is that more fun, but your team will be less dependent on you once they have built the habit of learning from each other.
3️⃣ Real World over Experiment
The best connection is built when the concepts are practised in real-world settings.
The small experiment in a learning hour may help some start a connection, but engineers may not be able to see how the methods can be practised in the codebase.
When you apply what you've taught in the team's codebase, chances are you'll discover that there are many concepts that the team have yet to learn.
For example, if you've been teaching about how to organise tests, questions might come up around the approach to mocking.
You can show the real examples applied in code, or more effectively practice the new concepts together in a pair programming activity.
Better yet, why don't you do it together as a team? The Samman method encourages the use of Ensemble working, which brings us to ...
4️⃣ Activity over Artefact
As a technical leader, many of the technical artefacts (including code) you produce are more valuable when they're produced together in a group activity.
A group activity allows you to scale better as you'll repeat less.
I used to fall prey to producing technical artefacts like the C4 Model or Wardley Maps, alone, later to find out that it didn't mean anything to others when I presented it.
Concepts that were new to others at the code level had the same effect: they didn't mean much to others.
The Samman method encourages coding in a group activity i.e. Ensemble programming.
Ensemble programming definition by @WoodyZuill: "All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer".
Ensemble programming allows you to get others to see how you'd bring new concepts into the codebase.
Best of all, given that you'll be rotating the typist around, others will also get to practice the new concepts in the codebase, finally making the ideas concrete!
If you're concerned about the productivity loss from Ensemble programming:
1. Think about the time savings you get from wait time.
2. Think about the long-term productivity gain from the learning.
3. Think small, you don't have to do it all the time.
To get more in-depth experience on how to use Ensemble working to teach software engineers, check out "Learning through the Ensemble with @ClareSudbery" interview video by @mob__mentality.
That's a wrap!
The key to scaling learning is to ensure that effective learning is happening even in your absence, and the Samman method will help you do that.