To become an expert in any field, the experts themselves agree that you need to engage in something called “deliberate practise”. This is practise with the express intention of improving your skill. It means working on things that are just outside of your skill level and putting in the time until you master them. Frankly, this sounds like a textbook definition of just about every master coder I’ve ever worked with. They are always working with things they don’t quite understand; always pushing a language or framework or tool just a bit beyond their own bounds trying to see what happens. That’s what separates the truly amazing developers from everyone else.
As a manager you need to find a way to facilitate this process. I think there are four key ingredients to unlocking “deliberate practise” on the part of your developers: access to information, a worthwhile project, time to work, and a chance to teach someone else.
Access to information is pretty easy to provide. You could send people to conferences or pay for in-house training. But absolutely nothing can beat the dollar-value of books. Every software development group should act as if they have an unlimited budget for good books. And of course, there is always blogs, how-to sites, and numerous troves of online documentation. These days there is really no excuse for not finding more information about a desired topic than you can use.
Once you have the information, you need an excuse to use it. This is where the deliberate practise comes in. While some people can learn from simply reading about something, most people need to actually use the knowledge as they are learning it. That’s why there are so many “getting started” books out there; they walk learners through a simple project that applies knowledge at the same time it is being learned. I like getting-started or quick-start books. I think they can accelerate the first stages of learning a new technology or skill. But they are wholly inadequate if you are trying to become an expert.
You can never become an expert in a new language, tool or technology until you’ve had to complete your own project, from scratch, without a book walking you through the process. You need to make sure your future experts have a genuine project to complete: something worthwhile, non-trivial, and sufficiently difficult. Work with them to identify this project in advance, before they even start reading the first book. The project is their goal, not reading the books. This has a remarkable way of getting people to focus and avoid the mental crash that often happens once initial interest in a new topic starts to wear-off.
Once they have a project and a way to learn, they need focus. Nobody will ever become an expert if you tell them to work on this new project “when they have some free time.” Developers need permission, and perhaps an order, to reserve specific time to work on their learning project. I’m not going to give advice here on what that time should look like. But if it isn’t specifically carved out of the daily schedule, the learning will not happen. It’s that simple.
Let’s assume that your future expert has books and materials; they have a defined project with written objectives and milestones; and they even have a full-day every week dedicated to the project. They’re still missing one of the most important things they require: an eager student. No one has ever become a master without first having a student. If someone is to become a true expert, they need an opportunity to teach someone else what they have learned.
As the development manager, you own responsibility for this one. Perhaps you can invite the new expert to present what they’ve learned to the rest of the team as a “Lunch and Learn”. Maybe you can request they write a couple blog posts for the dev team’s Wiki. If you have the right environment, maybe you can invite them to share their knowledge with another development team, a university research group, or a local user group. They important thing is that any new expert needs a chance to teach what they’ve learned. Hopefully over and over again. Only when we teach someone else can we truly become an expert.
To teach is to learn twice. – Joseph Joubert
If you can provide these four key things: information, a worthwhile project, time to work, and a chance to teach, you can create new experts for your team. If you have selected your experts well, this effort can pay huge dividends in your team’s velocity and the quality of everyone’s work.