How to Build a Learning Organization: Step 1 - Training
One of the biggest jumps you will need to make to take a small team to medium size and above is to formalize how you grow your team members.
What I hope you take away from this blog:
Training is the first step towards growing your staff
It's easier, cheaper, less risky, and less varied than trying to find and hire senior staff
You almost certainly aren't training enough
When you're small, you're all learning all the time. Anything worth teaching to each other is usually ad hoc. Specializations form. Most knowledge is in people's heads; but this doesn't matter as the work hasn't overwhelmed the team.
When you begin to grow - well, by definition - the knowledge is not in the new employees' heads. Moreover, where the knowledge lives may not align with your current strategy. In other words, if silos have formed due to lore being more important than documentation, then where the information lives may imply a different org chart than what your strategy would otherwise prescribe.
What Is a Learning Organization?
A learning organization is all about getting things out of people's heads and into other people's heads. Both the discovery of new information but also the dissemination of that information
The overall method we suggest is a combination of a few mental models.
Mental Model 1: Dreyfus Model of Skill Acquisition
First, consider the Dreyfus model of skill acquisition.
Note that there are five levels; we often combine novice and advanced beginner.
The takeaway from this model is that different approaches to learning are required at each level because they're ultimately having to learn something different about the subject.
It's often said that novices need to learn strict rules, while experts have transcended rules. There's a step-by-step process in between the relationship between the learner and the rules.
This blog is going to focus specifically on those novices and advanced beginners. Hence, "step 1."
Mental Model 2: Situational Leadership
Situational Leadership isn't what I'd call a leadership theory. Instead, it's a theory of a portion of management: delegation. How do you delegate?
Delegation is the core skill when it comes to scaling. How will you design an organization that can handle the scale you need - what will the end look like, and how will you delegate authority and expertise to build that organization?
Organizational design isn't that different from software design if you think about it. Some of the same concepts apply - cohesion and coupling. They're both charts with lines and boxes.
In this metaphor, delegation is refactoring. It's the only tactic you have that moves authority from one part of the organization to another.
The situational leadership model is a roadmap for how to delegate. However, it starts specifically with low-skill and low-will workers. How do you turn those folks into people capable of being delegated to?
Again, the first step is formal training, which we're describing here.
Mental Model 3: OODA Loop
In our post on the fundamentals of agile practice, we argued that if you manage to get the OODA loop into your organization, the rest of Agile, Lean, and other significant processes will come in time without much effort.
A learning organization is about how a group learns new information and how a group of people disseminates that information. Just as delegation is your only tool to "refactor" the organization, the OODA loop is your only method to learn new information. It's your only tool of discovery.
Since we're mainly talking about the first steps towards a learning organization, we won't talk as much about discovery here. But be assured, it should be humming along in the background.
Why Is a Learning Organization?
We've gotten this far about what a learning organization is and how we'd suggest you build one, but we haven't talked about why you'd ever want it.
Capitalism - as we've mentioned in other posts - is about using various kinds of capital to solve problems. In the case of a business, it's about building and maintaining capital that gives you a sustainable competitive advantage.
One of the most under-invested forms of capital you have is human capital.
If you are a Big OH culture - you value taking risks and are open to new experiences - then one of the main ways you compete is to have better ideas than the competition.
Who has ideas? Humans do. Who executes those ideas? Humans do. The quality of their ideas and execution is a product of the company's human capital. How much has the company invested in them?
One dollar invested in training yields thirty dollars in increased productivity over the next three years.
Yet, many organizations have small training budgets and manage to still not spend all of it at the end of the year. You're leaving productivity on the table.
I've heard a stat thrown around that it takes an employee two years to get up to speed at a new firm. But at many FAANG companies, that's near their average tenure! They're taking two years to get someone productive; then that person leaves.
Learning organizations can speed up onboarding to get people over the well-known and understood initial humps of joining a new team and get people productive faster. Additionally, ensuring your staff grows will help them obtain mastery, which is an intrinsic drive for many people and will help retention more than cash will.
Instead of training your staff to do the jobs, you need them to do, why don't you just hire people who know how to do it already?
First, if no one is training - and empirically, no one is - where are you supposed to find these people?
Second, if your answer to the first question was raising wages until they find you - you're correct; that's the only way to find people who manage to do well. However, when you raise wages to go after this scarce talent, you also attract a lot of imposters who are very good at making you think they are talented.
Since you, by definition, don't have this talent, you won't have any idea who's qualified and who's not. This is one reason organizations tend to accumulate barnacle-like people who are paid a lot, but no one is exactly sure what they do.
Third, when you hire experienced and senior staff, you bring their past companies' processes and culture. Is this random assortment of beliefs, traumas, and sacred cows lined up with your strategy? Does Global Corp Inc do things the way you plan to do things at your startup? Do you even have any quality control over what kind of "experience" you're hiring?
All of these questions are avoided with a strong learning organization. Here you take control over how things are done precisely and expose the levers of human capital to the company's strategy.
Types of Training
There are two significant types of training in our approach that you want to focus on.
The easiest to identify - as well as the easiest and cheapest to implement - is external training. This is training from vendors (like us!) that you can purchase off the shelf.
You can find external training of reasonable quality "off the shelf" with some research and trial and error.
Generally speaking, formal academic style training (lectures, slides, exercises, workshops) will be really good for Dreyfus' novices and advanced beginners. In fact, I'd say you can actually train your way straight through novice on nearly any public subject and set yourself up as a relatively solid advanced beginner.
Don't be fooled by "advanced" training. It's very worthwhile, and you want your people to take it. But anything that can be boxed up will almost certainly just be in the "advanced beginner" stage.
Outside of vendors who do this for a living, another excellent training source is conferences that offer it. These are not the tech talks at conferences, though those are valuable too. These are usually add-ons at the larger conferences, and take your folks through exercises and a more structured curriculum.
You absolutely want to buy as much of this as you can. It's essentially a commodity, so it's cheap. Moreover, there are literally zero reasons why you need to put together training on the basics of Agile or the basics of Scala. These are off-the-shelf concepts. Someone else is already selling this for cheaper than it'd take you to build it yourself.
Don't get me wrong, you will need training on how you do Agile and how you do Scala. And guess what, no one is selling that because no one knows how you do things.
Internal training is the compliment. These are resources that you put together yourself:
Internal training needs to be developed with the assumption and foundation of external training. It is a complete waste of your time to explain the basics of Python; you need to focus all of your internal curricula development on the particulars of your systems.
Again, internal training will help tackle many novice issues within the domain of your systems, thus bringing people closer to the advanced beginner. Additionally, by providing specific advanced trainings on features, tools, and techniques that are common at your organization, you can round out employees' skill level at advanced beginner for more core skills like programming ability.
The key to internal training is to empirically capture knowledge, organize it, and check compliance.
Think of your retrospectives, post mortems, and other regular check-ins. You may also want to think of design reviews and meaningful status reports. All this knowledge needs to be compacted into something easy to digest.
The most significant difference between an employee of two years tenure and an employee who was just hired is that the former sat through many status meetings and the latter hasn't.
You want to focus on bringing people with zero knowledge up to speed on:
The problems the company is solving
How the company is doing so
You're stuck in wishful thinking if this is just a short talk with their manager or a buddy. Years of status meetings, retrospectives, and design reviews can't be compressed into a brief discussion without it being LOSSY AS HELL compression.
Plus, it's actually a lot of effort to repeatedly do this short talk with each employee. It's less effort to just try and do one long talk once that everyone needs to review when they're hired. This extended talk could very well be weeks and weeks.
But if you've managed to get years and years of experience losslessly captured into weeks and weeks, you'll find your staff has a lot more "tenure" than you'd otherwise expect. Totally worth it.
Like code, this stuff needs to be kept well-factored, well documented, and up to date. When systems change, not just the documentation for those systems needs to be changed, but the training for those systems needs to be changed.
In fact, why do you even have documentation? All you need is training. Write all your docs as if you're training someone up on the system.
Keeping this readable, approachable, understood, and well organized is challenging. It's not something you'll get people to just do on a whim. Like code, you need to have some conceptual clarity (e.g., a good "design" or "architecture" view) of all this training and how employees, both new and old, might navigate through it.
This is where many teams fail. They may try and document their decisions. Still, they either fail to compress them or fail to organize them, making their path to a learning organization fraught. A new employee might have to get up to speed in 5 years of meeting minutes.
But that's still better than nothing, even if it is a snoozefest.
Just like school, how are you ensuring new employees have completed specific course loads? How can you ensure you have quality control on all the people's training?
This isn't a trust thing. Keeping track of who's seen what is the "unit test set" of training. Sound training systems will be complex because the problem your company solves is complex. You don't need to put the cognitive load of "what do I know and what do I still have to learn?" on the employee if you can use a system to check off and keep track of what they've learned.
Let's look at this in action.
On-Boarding and Indoctrination
As we said before, if you just throw new employees into the fire and expect them to learn over time, you're going to get terrified employees, AND it will take about two years before they're productive. Yuck.
It's way cheaper to invest the time to train them upfront and get a productive and 'tenured' employee far sooner than you otherwise would have.
Onboarding is a good target for an initial chunk of formal training.
I personally would recommend against allowing folks to "CLEP out" based on experience - keeping everyone in the same program lowers that program's complexity and ensures you have a high standard of expertise at the end. Someone may say, hey, I know Python - and they may very well know a lot of it. But there may be one or two features taught in off-the-shelf classes that you use heavily at your company that they do not know.
This is a great value check, too. People who aren't willing to review the basics may not be humble enough to share your values on other questions. People who find it offensive that you'd ask that they walk before they run may have egos too large to fit on your team.
Insofar as your internal training, onboarding is a perfect time to indoctrinate. Show people the workflows you use and how you do things. Use workshops to simulate projects, talk about the company's history, the history of systems at the company, and so on. Help people feel like they're a team member by giving them all the inside jokes and lore that the more tenured folks have.
Let's say you have a handful of senior people - hired with experience - that you've never trained.
That probably is a lot of people reading this blog, as they're looking to install a learning organization, so they probably don't have one.
I'd highly recommend you try from soup to nuts to go through even the basics. Again, as in onboarding, have your senior folks take basic training.
The benefits are the same as the above: standardize expertise on the other side. It will help you know where to start to look for and build advanced and tailored internal training.
But, during the bootstrap phase, you'll get an additional benefit - senior people can grade whether training is good or bad. Should a class they take be required of all new employees? That's something you can use their experience to grade.
What's Next? Mentoring
So let's say you've put in all the work, and now you require basic online classes in Elixir, Postgres, and Ansible for all new recruits.
You've also put together:
a video series on the history of critical systems at the company
walk-throughs of the code
some diagrams of how things work
and quizzes to help with memory retention
This is all great, and you can continue to build that part of the system.
But how do you get people out of advanced beginner in the Dreyfus Model? Or, in situational leadership, you now have people with enough skill to be dangerous to keep growing such that they can be delegated more and more authority?
The solution there is a great mentoring system and something we will cover at a later date.
Formal training programs - think classroom style - are the cheapest and most efficient way to educate novices and low-skill/low-will employees to get them to the next level.
Using off-the-shelf classes is the easiest way to get started here, and focusing your internal training efforts on things specific to your company compliments that.
Most places under-invest in training despite the vast benefits.
Training is only the beginning of building a learning organization - as people get more expertise and seniority, they will need different interventions to keep growing.
Want to learn more about Guildmaster's approach to training and learning?