Training is important. Nearly every job, nearly every department, nearly every company will at least tacitly acknowledge importance of training.
However, the effectiveness training when it is implemented is limited. Why? Because nearly always, the training involves long periods in a room with someone yammering on for at least an hour (and often much, much longer). The ideas are useful but often too abstract for any attendants particular needs.
They are engaged in what I’ll call ‘macrotraining’.
Macrotraining means big ideas, a sage on the stage, calendar events with reminders. Don’t get me wrong, those things have a place. Yet, the places where I’ve had the most growth didn’t have very many of these trainings. Instead, learning was embedded in daily work and occurred spontaneously. It was certainly still a form of training, but it’s what I would call ‘Microtraining’.
Macrotraining vs Microtraining
Macrotraining is what most people think of when they think of training. Here are some of the traits:
- Scheduled: It happens at specific times that everyone dutifully marks on their calendar,
- Explicit Instructor/Student Roles: Someone is imparting knowledge either by lecturing or leading hands on exercises,
- Large Scale: Topics are abstract and are made to be applied to future scenarios.
- Good for Big Ideas: Good for generating ideas that will be implemented later (think conference presentations).
More on that last point, macrotraining is good for making big leaps. It’s important when an organization/department/team as a whole needs to make a big leap. Everyone needs to buy in. Everyone needs to get a baseline of knowledge quickly. Everyone needs a shared framework and language for moving forward. Examples might include, moving to a new version management system, starting a new service, changing product focus, etc.
While macrotraining is good at making big leaps (at least in theory), microtraining is about continual improvement. In fact, most organizations think the hard work is done after a macrotraining session. Actually, the easy part is done. The devil, as they say, is in the details. And that’s where microtraining thrives.
Here are some traits of microtraining:
- Spontaneous: Training occurs when there is a specific need and happens continually throughout the day.
- Democratic: Everyone can participate even if the feedback is “I don’t understand what this is doing”.
- Specific: The discussion is about solving a particular immediate problem or question. This does not mean that the discussion cannot go abstract, but it moves that way because the discussion requires a knowledge of an abstract concept. See more below.
- Good for Growth and Continual Improvement: Microtraining is about getting slightly better over time.
Microtraining and macrotraining mirror each other, but microtraining is seldom discussed and nearly always undervalued.
What Does Micro-training Look Like
Microtraining, in short, is the willingness to give continual feedback and advice.
Here’s a couple of examples:
Learning a New System
Jane is a new developer and has expressed interest in the deploy process.
The Macrotraining approach would be to schedule a training session in a few weeks. Some engineer will write up a few powerpoint slides and then run through a demo. Everyone will feel happy, but Jane will always feel anxiety about dealing with the deploy if she’s the only engineer around during a fire.
The Microtraining approach is simpler. Jane expresses interest in the deploy process to her fellow developer Ramit. Ramit says “cool” and next time he is about to deploy code he’ll walk over to her desk and he’ll walk her through the process, stopping to explain any concepts that my be new or unfamiliar.
That’s the easy part. Here’s the hard part. The next time there is a deploy, he walks over to Jane’s desk and he says “go for it.” She’ll have forgotten 95% of the steps, but at each point he’ll wait for her to puzzle through the next part, making suggestions if she seems really lost until the deploy is live. The next time there is a deploy. He does it again. Eventually Jane will have mastered the process.
Is it faster? In a way it is, because though there are more sessions, Jane will master the material much quicker. More importantly, it is personal and immediate (the deploy has to go out after all).
The beauty part is that Ramit has a backup for this process and if he is out or busy or whatever, he knows someone else can take over.
Improving Code Quality
Jack is an intern at Hip.io a small web company. Part of the company policy is code review on all code. Jack doesn’t know much about code reviews, but his supervisor says it’s not a big deal and tells him to make at least one pull request a week even if something is not all the way finished (it won’t be merged, but a week is long enough before getting feedback).
After the first week, he puts up a small pull request, a couple method tweaks. His very nervous and makes a note about how it’s not very good, and he’s still working on it. A few other developers comment on it. One suggests a method that would simplify a sub-routine. Another reminds Jack of code styling issues on a few parts. Another suggests that a change could have an impact on a different part of the code and links to the code that is potentially affected.
All in all, Jack feels pretty good. There were changes he will need to make, but it wasn’t as terrifying as he expected. As the weeks go on he starts making comments on other code. First it’s a few style changes, but then he makes more and more suggestions.
At the end of the summer, he’s noticed a significant improvement in his code craftsmanship.
That all seems so simple that it’s a wonder that I’m writing about it at all. But here’s the secret: Microtraining has to be deliberate.
Normally, we let work gravitate to those with the most experience. If someone has a problem, they may ask for help and what happens next is fairly typical. A more experienced person will “look at it” and then after a bit, respond, usually by email, that the problem is such and such line and they need to change it to so and so. Inexperienced person copies and pastes and that’s the end of that.
A more charitable experienced developer will walk over to the desk of the questioner with the intention of teaching them something, but, as with most programming problems, when they answer isn’t immediately apparent, they, the experienced developer, will commandeer the keyboard and work at it until the problem is solved. The whole time the less experienced developer either sits and stares bafflingly at the screen or just tunes out altogether.
I’ve seen some newer developers so trained to expect this, that the minute I walk over to their desk, they push away from the computer as if they just expect that I will want to take it over.
Each of those examples solves solves the technical problem. But, it’s not microtraining; there was no improvement in the process.
Here are a few of steps to add microtraining to an organization:
Make improving each other’s craft an explicit part of a job
This means changing the culture so everyone contributes. Some people may only feel comfortable commenting on pull requests. That’s fine.
Oh, and by the way, everyone needs to contribute even new developers and interns.
With interns, a good exercise is to have them lead a demo or walk someone line by line through the code. They will mostly be on the receiving end of feedback, but they will be learning to articulate their coding decisions.
Encourage giving and receiving critical, but positive feedback
A mistake a lot of places make is only giving ‘feel good’ feedback. In other words, they’ll say “that looks great!” or “I like it!”.
A good organization gives critical feedback, but works to make sure that the goal is improvement and not criticizing an individual for “not knowing” the right way as if we were all born knowing to code.
Never, ever, take over the keyboard
This will make each interaction twice as long, but it’s worth it.
Find out what people are interested in and encourage them to observe
This is the closes microtraining gets to planning. Some developers are good at being proactive, some need encouragement. Find out what they are interested in and have the observe one of the senior people as they work on it. The senior dev will, of course, be explaining what they are doing.
If people don’t have an interest, well, then pick something for them. Part of microtraining is learning to appreciate stretching to learn new things.
In the end, an organization built around learning and continual improvements will be better overall. There will be quantifiable business benefits (fewer bugs, faster fixes during fires), but the majority of benefits will be harder to quantify (cleaner code, team cohesion, higher morale). It’s not difficult, but with most things in life, the hardest part is making it a part of the culture.