I have managed an application development team for 3 years now. One of my core beliefs is that as someone's leader, it is my job to help them grow and learn. Learning is not confined to just technology skills, but at its core, application development is an engineering discipline, and there is just no way to escape the fact that you need good technology skills.
Often times you will see people who are 10 years into their career, but the work they do is that of a junior level software engineer. They don't know about breaking code into different layers, using design patterns or how to distribute responsibilities between different components. Sadly, too many people are 10 years into their career but don't have 10 years of experience. They have just repeated their first year 10 times.
I do firmly believe that every professional needs to take responsibility for their own development. No one can learn for you. You have to make an investment in yourself if you want anyone else too. At the same time, too many IT leaders are just worried about meeting project deadlines or insuring the next release doesn't blow up to devote the time to making sure their people get the skills development they needs. This is unfortunate and only contributes to people gaining another year of tenure but not of experience. Oh yes, we fill out an individual development plan every year in January. But then it is stuffed in a drawer not to be seen again until the following January.
Sound familiar. Unfortunately this is all too common.
A Better Approach
A few years ago, if you wanted training, you would find a class at a learning provider in your area and sign up. This involved being out of the office for about a week and the cost was generally somewhere between $3000-$5000. While this is still the best way to learn some things, there are several shortcomings to this approach:- You are taking a course on someone else's schedule. Too bad you need to know how to write a WCF service next week. That course isn't offered again for another three months.
- The cost. Sadly, most organizations budget very little per employee for training, and certainly not $3000+. So the result is often times only a handful of employees get to go, or maybe none at all.
- The throughput. Because of time away from work and the cost, you are effectively limited to taking one course a year. The problem is that the way software development has moved over the last 10-15 years, you need much more than that.
I've always been a fan of the Pluralsight model. Long before I auditioned to become an author, I had my own Pluralsight subscription. Even 3 years ago, when the catalog was much smaller, there was still more training than I could ever hope to watch. The training is up to date on current subjects, and I can watch as much or as little as I need to in a given week. All for $50 a month.
Making Pluralsight Work For Your Team
The purpose of this blog post isn't to be an advertisement for Pluralsight. It is about how to make Pluralsight subscription work effectively for your team. This is all about outcomes. If all you do is buy subscriptions for your team and say "go at it", you are most likely not going to get the outcome that you want.
What I have done with my team is come up with a personalized development plan for each person, based on where their current skill level is at, where their interests lie and what our needs as a team are going forward. I then break this down into the exact courses to watch and a schedule of when they are going to watch what modules. Generally, everyone is assigned to complete two hours of training a week. I tell people to block that time out on their calendar to make sure that they have time reserved to complete the training.
Here's a sample of what a plan might look like for someone who is new to C#.
Employee: Joe Learner
| Course | Module | Time | Complete By |
|---|---|---|---|
| Accelerated C# Fundamentals | An Introduction to C# | 53 minutes | July 7, 2014 |
| Accelerated C# Fundamentals | Classes and Objects | 49 minutes | July 7, 2014 |
| Accelerated C# Fundamentals | C# Types | 59 minutes | July 14, 2014 |
| Accelerated C# Fundamentals | C# Events, Types and Methods | 55 minutes | July 14, 2014 |
| Accelerated C# Fundamentals | C# Flow Control and Exceptions | 49 minutes | July 21, 2014 |
| Accelerated C# Fundamentals | C# and the CLR | 52 minutes | July 21, 2014 |
| C# Collections Fundamentals | Introducing C# Collections | 31 minutes | July 28, 2014 |
| Accelerated C# Fundamentals | C# and Generics | 46 minutes | July 28, 2014 |
Part of the reason for doing this is to provide everyone with some structure. Spelling things out like this, printing it out on a page and handing it to someone helps to clarify exactly what the expectations are. And now this person knows exactly what they need to do. This is much better than making a vague statement like "Check out some of the courses on C#. I think there are some good ones out there."
Then, each week in everyone's weekly one on one, we devote about 30 minutes to discussing the training they completed the prior week. Doing this every week has several effects.
- First, it puts front and center that personal development is a goal, for the team and each individual. This constant reinforcement helps everyone to see personal development as a habit, not something that you just do occasionally. This is essential. We want to create an environment where we are in the mode of constantly sharpening our saw. We want to make learning part of who we are, our identity. Following up every week helps reinforce that notion
- It allows each person to ask questions about things they didn't understand. Don't get me wrong, there are lots of great courses, but nobody understands everything 100% the first time. Maybe there is a concept that just didn't resonate with that person while watching the video. No problem, that is what I am here for, to help clarify those concepts and cement what has been taught. I tell everyone take notes during the videos--just like when you were in college. And write down what you don't understand. Then we can go through it together to make sure that you are mastering the material, not just checking off courses you have been watched.
- It allows me to ask some probing questions to see how well someone understands the material they just watched. My purpose here is not to be cruel or show someone up, but to measure understanding and reinforce concepts I have found to be especially important. Sometimes someone thinks they understand a concept, but in reality, they are a little fuzzy on it and don't want to admit it. Sometimes they think they understand but maybe they don't really understand to the depth that they need to. This is OK. I want to identify those things so we can work through them now. Maybe that will be scheduling some extra time with someone to go over the concepts again, but I would rather find out now than in 6 months when we are doing a code review. This also gives me an insight into if we need to speed up or slow down for each person.
- We have also started to incorporate some coding exercises for some core concepts that we want everyone to learn. Much like an assignment in college, we give everyone a piece of code and have them put together a solution. Then we'll talk through that solution in a future one on one. Sometimes, people find things we a whole lot easier when the Pluralsight author did them in the webcast than when they try to do them on their own. Again, this is OK. It gives us a way to find out what the blocker is for someone and help get them over that hurdle. Again, the outcome we are seeking is mastery of the material so they can apply it in their other projects.
This does take a lot of time, and when I say that, I am talking about my time. I myself watch every webcast that one of my people watches so that I can effectively speak to what the author said and help clarify if need by. It also means that I will spend some extra time outside of one on ones helping people in extra sessions when something doesn't make sense. Is it worth it? The answer is a resounding YES. Again, one of the core requirements of my job as an IT leader is to develop my direct reports. In many ways, this is my most important deliverable to the organization. Leaders are supposed to be multipliers. This is one of the ways I am a multiplier for my organization, by growing the next crop of software developers who have the skills we need. I really couldn't think of anything that is would be more important for me to do most weeks.
So what do my people think? I think you are always afraid that when you push something as a leader, you will come across appearing heavy handed. As it turns out, our people love it (I say our people because one of my fellow leaders is doing the same thing with his team). People say that in years past, they had learning goals, but even when they completed them, they never felt like they really learned something. Now, having someone to discuss what they learned with and doing it right after they viewed the material really reinforces those lessons. Multiple people have told me that the constant follow up is the best part.
As it turns out, it is also a exercise that builds trust within a team. Sometimes, someone doesn't know how to do something, but they are afraid of admitting that to their manager because they will get yelled at or even worse. But through this experience, one of the things your direct reports learn is that you really care about their development. They see the time invested in them and they see that this is about making sure they are learning, so it becomes easier for them to talk about areas they don't feel comfortable. Part of creating a learning culture is letting people open up about what they don't know so you can put a plan together to help them over that hurdle. Working together to identify and resolve these items helps build trust in a team.
Putting a Plan Together for Your Team
Usually one of the hardest things to do is to get started, so if you are still with me at this point, hopefully you are motivated to get started with your team. What I suggest is putting a plan together for each person that encompasses about 3-4 Pluralsight courses such that you end up with about 20 hours of video to watch. This will end up taking about 3 months because some weeks people may only have time for one hour, people are out on vacation or a myriad of other factors.
What is important though is that you and each of your team members spend some time on learning each week and discuss it on a regular basis. If you want, you could discuss every two weeks rather than weekly. I wouldn't go a month, because that is too long and after all, part of what we are trying to do here is create a habit. So commit to having everyone watch at least an hour of courses a week and follow up with them to see what they learned and how they are doing.
What if you are in a leadership position but you aren't technical? In that case, have one of your senior developers or an architect review the material with each of your developers. This may require reaching out of your group to find this person who can mentor, but it is as important to have that follow up with each person as it is to watch the courses in the first place. Make sure you select someone who is a good mentor and can clearly explain things to keep the experience positive for each of your direct reports. The most important thing is that your people have someone they can go to when they have questions.
I think what you will find is that people will embrace learning. Teams often take on the personalities of their leaders, so if you as a leader put a priority on learning, team members will too. Most people will be impressed at the investment that you are making in them to grow their skills. And that is the outcome we are after. Better developers who have better skills who can take on larger and more complex projects and produce better results.
That is what has worked for me. If others have any other ideas, I would be interested in to hear about them in the comments section.
