How can I learn to effectively train underskilled staff?

Question

Background: I'm the sole application developer working at a data processing company. Because of this, I have a pretty high "bus factor" and everyone knows it. Management is keen for me to pass some of my skills and knowledge on to other staff and it's obviously a good business decision.

However, there are two problems with this.

The first and most pressing is that the staff I'm being asked to train are underskilled. They're both long-term database developers who have, in their distant career background, worked with middleware and front-end technologies. But we're talking 10-20 years ago. I know from practical experience the knowledge shortfall is colossal.

To further complicate the issues, I am self-trained. Almost everything I've picked up has been on the job experience. I have no idea how to go about structuring people's training in a useful way. Nor, for that matter, how to learn how to do so.

I have voiced these concerns to management, who have said that they're happy so long as I try my best. They want to see me provide training meetings, technical documentation, learning material, that sort of thing. I will not be judged on how effective my methods are, so long as I attempt them. This seems reasonable.

However, I'd obviously like to try my best to make my time and effort on this worthwhile for all involved. Where on earth can I start learning how to train when I'm not a trainer, have never been trained, and my pupils are way under the standard required?

EDIT: After making "hot questions" I can see three outstanding answers here. No idea which to select. I may have to take a few weeks to see which set of suggestions works best. Thank you for all your useful advice.

Answer 1

As a data specialist, I would be extremely annoyed if someone wanted to try to make me into an application dev for the bus factor. That is just shortsighted on the part of your management. It is like asking an accountant to train to do HR. I only bring this up because you are likely to face resistance from these people. I also bring it up because they are not unskilled, they have a completely different profession and if you treat them as being unskilled and stupid it will come across in your training which will create problems.

I believe the first step is to identify what things they will most likely need to be able to do and document them in a Wiki. It is unlikely that they will want these people to create things from scratch but to troubleshoot and hold things together until you return or they hire a new application developer. If this is true, then triage what you want to tell them down to the most important things. Make a list of the most common production problems and then create a cheat sheet for each problem on what to do to fix it.

Teach them things like how to interpret error messages and how to find information in whatever logging your system is doing and when to reboot the server and what will be affected if you do so. Teach them your coding standards. Teach them where the code is stored in source control and how to use that (while I think most database work should be in source control, it is not in many places, so they may not know how to use it.) Give them a list of any applicable server names and passwords and ensure they have the appropriate rights to work on those servers.

Find a local contact for a place that has freelance devs available. Make sure your company knows that they can get support from these people if the problem is beyond the skills of the data people. You, the data people and ultimately your management will be happier if there is a fallback plan. The chances that you can turn these people into application developers in a short time is low. The best you can hope for is that they can fix simple problems and they know where everything is and can explain the business to a freelancer for complicated things.

The document everything you can. The goal is that people can find what they need to do the work if you are not there.

I would also suggest that you start a process of code review with these people. In this case, it is not so much to find code problems as to get them familiar with your most recent code and its requirement, your style of coding and your thought processes about your design. Along the way in explaining things to them, you will likely notice some bugs you hadn't noticed.

When you have a common production problem to deal with after you have gone over the most common issues in a training session, have them shadow you and document every step you take. Make sure you make it clear to them that you encourage questions. If they do the documentation, they are going to be more likely to write it in the way that is best for them to understand. Different people have different learning styles and you are basically creating a Wiki that will be more useful to them than you. So let them decide how to organize it.

If their duties keep them from shadowing you, then do the wiki entire yourself as you work on the problems while they are fresh in your mind.

For some simple problems, after they have shadowed you and the steps have been documented, then you have them take the steps while you shadow them. This will give them more confidence that they can actually do the task. This is what we did when we converted some application devs recently to data specialists.

The basic teaching philosophy should be

• Identify what needs to be trained concentrating on the most common issues
• Make sure that they have access to the things they need to access to deal with issues
• Create documentation
• Go over the steps to perform the task
• Have them shadow you and create supplemental documentation that meets their needs
• Shadow them performing the task using the documentation while you are available to help they get out of trouble if need be.

Answer 2

There are plenty of courses on how to train people, some online, some are from real-world learning institutions. I don't think you have time for this.

So, let's get started with a 10 minute crash course.

1. Document the processes: Your starting point is going to be your product documentation. Every detailed step, every reference, every additional technology that it hangs off of. Get it on paper.
2. Establish base line: Establish a minimum skill level that needs to be met to understand your documents. For example, handing over app support may require C# knowledge, SQL ability, Cobol... Establish a base line by listing the base skill level for each technology. Don't forget Windows, some people are idiots.
3. Develop a plan: Once you have your base line, start putting your documentation into a training plan. This is going to take time. Start with the simplest concepts and build on them. Remember, you're writing this on the assumption that a contractor could come in and hit the ground running after your bus incident.
4. Test it: Test your training on someone. They will find the holes that you overlooked. Fix the holes, rinse, repeat.

As with everything, each step can be broken down into more detailed steps. Have a google/bing for writing technical documentation, creating training packages, etc.

Answer 3

I was in a very similar position a couple years ago - self-taught, sole owner of dozens of services used by hundreds of people, high bus factor. Your question exactly describes my situation in 2014.

A lot of these answers seem to suggest documentation, but this wasn't a good plan for me - my services changed rapidly, as fast as reorganizations or policy changes could happen. Documentation is notorious for being slow to make, and almost immediately out-of-date. It was a non-starter for me to try to retroactively put together spec pages explaining the minutae. And the only people reading it would be the underqualified people coming in to help me - who would always just end up asking me to clarify what i'd written anyway.

I tackled this in a couple ways.

1. Don't try to put together a series of masterclasses - you're busy. You're the only one who can do your job, so your time is precious. Invite your new people to shadow/pair with you while you debug an issue, or implement a minor feature. Don't wait for "the right" bug to come in, just grab one of your people and sit them down while you narrate what you're doing. It'll slow you down, but not nearly as much as trying to put together presentations - and it gives them direct experience. Pairing was (for me) the most valuable use of time for training - it gets new people on their feet very quickly compared to wiki docs.

2. Understand that you won't be able to teach them everything. It's less important that they understand line-by-line every class you made, and more important that they understand the geography of the code - if they understand what codefiles to go to in order to find how something works, that will help them a lot more than a deep-dive presentation going into one specific thing.

   Especially if your people are DBA's by trade, they're probably going to understand logic in terms of schemas first, and functionality second. Try to identify a few core data paths. Most applications take data from one or two main sources and mutate them upon user request. If you can identify this, then explain as much of this data path to your developers as possible. Physically walk through (in a debugger) what happens when a user makes a request, where the data comes from, what classes are responsible for loading/saving it, if you have caches then show where they live and what their freshness is expected to be.

3. Split the knowledge up. Don't teach them both the exact same things - if it's not some major part of your services, then don't be afraid to distribute it to different people. This takes advantage of the fact that they'll need time to absorb what they learn, but you can teach much faster than that absorption time. It also lets them focus on a smaller piece of the picture, even if it's still a big piece. You don't have to silo them, but dividing and conquering the problem space is useful.

4. You've probably got a few refactors you've wanted to do for a while - some screwy service that is really hard for even you to debug. Do them. And as always, grab one of your people near the end to show them how the refactored system works.

5. Talk to them, don't let them give you the polite runaround that they're following along. They're going to be lost and confused. Throw out a few phrases like "i know that was a lot to take in, it's pretty complicated. Did any of that not make sense?" and try to invite them to ask questions as much as possible - you can't teach them if you don't know what they're absorbing.

   Moreover, if they drop by and ask you a question, that is your highest priority, even if it's just looking at them and saying "I'm on my way to a meeting right now, it'll probably last 30mins, i'll find you afterwards".

6. After you've spent some time showing them the ropes, find something to hand to them. Some non-urgent task that you're fine with them taking a week or more to complete. Schedule pairings with them to see what they've got and where they're going with it - course correct them and give them pointers on how to code while you're at it (stuff like "you could use a foreach here").

7. Code reviews. Have them send you the diffs (or use a code review system) and go over them. Don't "grade" the reviews, just note where mistakes are, or describe how to improve. If there are no bugs, don't prevent them from contributing code (don't make them feel excluded by you) - but make sure there's an item for them to follow up and clean up immediately.

More importantly, since your team is obviously growing and you didn't mention intending to quit, now is the time to start getting serious about code quality. It's only going to get worse from here, so every class and method you (and they) edit from now on should get an autodoc comment. If you haven't already, start modularizing your code and trying to break apart methods that run on for hundreds of lines, and detangling nested classes.

Answer 4

Create documentation for a start, step by step procedures of what you want to teach with explanations of detail where necessary.

This creates a basic reference which you can build on and answer questions about and is probably the most important aspect. It also has the big advantage of concentrating your knowledge in a way you may not have attempted before. I certainly find it helpful even for myself, because a lot of things I do are quite complex and it saves me rethinking my way through a bunch of steps if I've done it before.

The rest is basically working off this reference material adding to it or modifying it as you go. Without it you'll just be jumping around here and there without laying proper groundwork. Half of what you taught will be forgotten quickly and you may miss a lot of steps by assuming they understand when in fact they got lost 1/2 an hour beforehand and have no idea what you're on about.

Answer 5

It sounds like your coworkers have general technical knowledge but are unskilled in specific technologies you require. This seems like a great opportunity for online courses such as Plurarsight or Egghead.

The truth is that most of us are not great teachers because being a teacher is a different skill set than what we are normally trained with. Instead why create lesson plans for basics of technology when there are plenty that are already out there?

You mentioned that management wants to see you instrumenting some plan, so how about asking Management for a Pluralsight subscription and spending a few hours every week going through one of the courses? That way you have

1. A high quality lesson plan that you didn't have to spend time on.
2. Its fully external, so there is no bus factor to the teaching.
3. An open environment for people to ask questions and collaborate.
4. An opportunity for your coworkers to do self-learning on their own time.
5. A chance for you to brush up on any basics you might have missed or been light on.

Answer 6

If what I am reading is true - that you are the sole survivor of the knowledge, - your own job security may be at stake in the sense that you may be dammed if you do and dammed if you don't put in place knowledge transfer.

I know the firm I walked for recognized a situation where all their eggs were in one basket (technical skill-wise) and decided to terminate a project and cut a business unit/division rather than try to dig themselves out of a hole that they should never have gotten into in the first place. The talented lead developer got made redundant when it became clear that the technologies employed had been superseded, and the cost-benefit of retaining a capability were not worthwhile.

The real question is... (irrespective of any quality control issues - since it sounds like the firm has little to loose in this respect at present) - can the company shaft you all - by taking it all off-shore using more staff costing a small fraction of present?

If "yes", then the clock is already ticking for you, it may be every man/woman for themselves - so I would be more concerned with your own retraining. Reskilling as a lead knowledge management HR/trainer (if you can get the firm to pay for it) may be a good safety net.

If the answer to that question was "no", then I wish you the best of luck holding onto the helm, - because if the strategic management of your firm are anything like as ruthless as one of my former employers - you may need it.

Answer 7

Assuming they want to learn then get them onto an introductory course for the technologies/languages/etc you are using. It doesn't have to be fancy, just something to get them started. Company money is much better spent getting someone who is a professional teacher to professionally teach rather than shoehorning you into the role.

Personally I learn much better by doing than by having someone tell me. Programming is a craft and a skill, not a matter of rote memorising. You should do that with them too. Don't get in a meeting room with them and talk for hours. Get out the computers and do some real programming.

Start small, really small. "Write this little app", "tweak this little script". Simple changes with a defined start and finish that should only take a few hours. The first few times sit down with them and walk through the process. You could even consider pair programming or similar. Have them shadow you for a day and start off doing the work, but each time you shadow have them do more and more of it while you give advice and in the end just watch.

Nothing but experience is going to give them experience. So the best thing you can do is give them that opportunity while at the same time providing guidance and protecting the company from any potential mistakes.

Answer 8

As someone in a slightly similar position, I can't emphasize enough to document both your processes and code, and keep them up to date. Even if there is already documentation, it doesn't hurt to re-write it, and highlight steps that may not be clear or that have changed over time. You should be doing this regardless of whether or not you are responsible for training, in case you get hit by a bus.

Start with documenting you regular processes. Write an outline and fill in the details.

If there is any coding involved, make sure there is at least a basic set of standards that everyone understands and follows.

Be sure to share the documents with your co-workers before you schedule training, so they can review and ask questions.

As for the training itself, one thing I have done in the past is to sit down and shadow my co-worker as they do the work.

Answer 9

Teaching is an entirely different skill set - it will take a long time and a lot of practice to get good at it. I think your best bet is going to be making the job smaller for yourself.

You said management mostly wants you to show you are trying, which is good. However, I am sure you and your co-workers don't like wasting their time, so you should probably try to make the efforts you spend worthwhile.

If I were in your shoes, the first thing I would do is meet with your coworkers and ask them what they are interested in learning. This will cut the amount of stuff you could be teaching them down by a lot. You will also get a sense of what they think their strengths and weaknesses are, and how that matches up with your perception. That will give you what you need to design the first "course." Consider meeting one-on-one if possible, since people will be more honest.

For your first course, don't reach too high. Using what you learned from your first talks, put together a list of the 1-3 most important concepts or skills you will need to teach them. If they are short, go with 3, if not, just stick with one. Then, plan to spend about an hour teaching them these things. Imagine you know as much as they know about the subject. What information would you need in order to learn the skill or concept? What exercises would help you practice them? Create a short lecture and example exercise for each topic. Also create a very short "homework" assignment to give them practice.

Doing all this will take a couple of days - so you can see why it is important to limit your scope as much as possible. After your first "course," you will have a much better understand of what your strengths and weaknesses are in terms of teaching. Now your mission is to work on the weaknesses while continuing to design and teach short courses modeled on what worked in the first one.

As you do these courses, keep your notes organized. These will become your documentation. As you get better at organizing and communicating information, the documentation will improve and will make teaching easier as well.

It will be difficult to teach yourself how to teach, but you actually have an advantage in being a self-taught developer - you know what you needed to learn to be good at your job. A lot of people who have only had good teachers never learn how to figure that out for themselves. The downside is that you also don't know many of the standard teaching techniques or ways of structuring training, so you will have to learn that part as you go. I would look for the standard textbooks in whatever language or area you are working in. That will give you examples of how to structure the knowledge.

Good luck!

Answer 10

Lots of good ideas. So far, I haven't seen any recommendations on developing some small videos using screen capturing tools. Document the processes using PSR.exe a lot of people do not know about this tool but its built into Microsoft O/S. It is a screen tutorial that you can annotate.

Answer 11

Most answers seem to assume the subjects want to learn (e.g. Tim B). I would take a step back and confirm this assumption, before figuring out the "how." When learners are dis-engaged and unmotivated, the training won't be effective no matter how good it is, especially in a hands-on discipline where practice is absolutely essential to knowledge gain and effective use.

I am assuming the goal is for these db developers to become proficient to the point of filling your big shoes, if necessary. Have they been asked if this sounds like a great plan, or have they proactively solicited training in these areas? Awareness off a business need, and proactive attitude toward realizing it are different things, requiring a different mix of conditions to sustain them. So while these devs might nod when the subject is broached by management in meetings, they may be passive at best, or even overtly resistant when it comes to actual learning and behavior change (as its objective).

There are a few significant benefits to taking a step back and confirming motivation to learn before actually jumping in with solutions:

1. Adjusting expectations and approach: if the devs are unmotivated and are likely to be passive learners, it will require one training approach, while if they are proactive about it the approach would be different (e.g., less oversight/hand-holding required, different incentive structure/progress monitoring, more or less autonomy given to learners, more or less flexibility required in terms of choice of topics, order of topics, presentation modality, etc.).

2. Saving time/effort by ensuring that the adopted training strategy matches learners' needs and goals for the training (e.g., avoiding spending time/money on creating job aids or subscribing them to online courses, only to see minimal use/progress). When people don't want to do something, they tend to excel at coming up with creative excuses and justifications for not doing it (e.g. workload, different learning styles). It may be difficult if not impossible to discern which of these excuses are valid and which aren't.

3. Starting off on the right foot. A great way to ensure that training will fail is to require (force) it onto the participants. On the flip side, a great way to maximize ROI on training is to create an incentive structure such that the participants would be intrinsically motivated to engage the material (i.e. self-driven to learn for learning's sake, such as when they are genuinely interested in the subject). When the latter is the case, participants will on their own adapt the content to their learning style, fit it into their schedules, pace the learning appropriately, etc. The best kind of learner is one who makes all these individualized decisions for themselves, with maybe some guidance/advice from the outside (when they need it). Just think about how much headache this can save you, and how much credit you can take for essentially getting these folks to learn on their own -- if you succeed in achieving such self-motivated learning on their part (which may or may not be possible).

I hope these thoughts help you to think more broadly about what is (or isn't) happening in terms of the way the training is being presented and structured, at to make some adjustments that will help maximize its effectiveness in the long run. Good luck!

Answer 12

Don't assume anything about their knowledge. Validate it. Instead of you saying they are underskilled, let some respected authority explain it to them. Microsoft, Brainbench, I'm sure there are more testing vendors out there. Brainbench used to show weak areas and strong areas, as well as test score and where you stand - all of this can be used. Doing a standardized test is important as it eliminates subjective factor.

Once the baseline is taken, don't train basic skills. Let others do it for you. Online courses, such as Udemy, Pluralsight and others can help get everyone to the baseline. This is much cheaper than any other alternative. And they may do a better job for two reasons:

• You may be outdated by a couple years. By the time you have everyone trained, the gap will be more. In order to stay on bleeding edge of technology, you need to stop doing business, most people can't afford that.

• They know how to train. And yes, there is science behind teaching. You cannot simply transfer knowledge into someone else's brain via USB. Nor can you talk it out and hope that your student remembers anything. Lots of psychology involved.

If you want to improve chances for success, research and pick courses for them. There is a lot of garbage available online, unfortunately.

Next step (or you can do in parallel) - Document what you know about the applications you've built on a high level. Suppose you need to explain to another developer like yourself who knows the stack, lots of experience, including the latest tricks, but who just joined the company and knows nothing about your code.

Start probing people if your documentation makes sense. Let them ask questions. Aggregate, see which area raises the most concerns. Go into detail there. Rinse, repeat.

Answer 13

There is a different answer to the problem of "bus factor". If something happens (I'd prefer thinking of you winning the lottery and deciding to quit on the spot, not an encounter with an actual bus), sure, the company is in a bad spot. But things will run for a while without you, and that is the situation where you get a contractor in for a short term solution, and you hire a new developer with the appropriate experience afterwards.

Sure, they'll have to pay good money for a good contractor who can take over from your work. But someone who is really good at this will have no problems taking over from you. And after a few months leave things in good shape for an average developer to take over. Retraining your colleagues to be able to do a job that they most likely will never do will be both expensive and not very helpful.

Just make sure there is nothing that is in your mind and nowhere else. Procedures that need to be followed to keep things working. Passwords that are needed (and that you are not supposed to write down). And instead of documenting things, when you do things where procedures must be followed, ask your boss to give you a secretary for some hours who writes down exactly everything you do, and who is strictly instructed to leave no details out.

Answer 14

Get them to do your job for a while.

For example, if your job as application developer is to develop an application, then assign to them your next application development task[s].

Tell them that:

• You want them to do the work
• You're available to answer their questions
• You expect them to take it on themselves to ask you questions

Because:

• You don't know what they don't know (that you need to tell them); so, instead of your guessing what to tell them, it's more effective if they tell you what they don't know and want to know (by asking questions).
• It requires of them to want to do the work, and to engage themselves with figuring out how.
• It ensure all training is relevant to the task at hand: that it's necessary and sufficient.

Given that you're able to do the job, you're presumably able (if asked) to explain any specific aspect of it in any amount of detail.

Expect this (training) to take some time. Hopefully, management expect that and are OK with that. When I helped (trained) new hires in this way, I approximated that it would take me as long to explain a task in detail as it would have to actually complete it myself; it took even longer than for the new hire. For example, a job (e.g. a new feature) that might take me three days to do by myself would take me three days to explain in detail, and take the trainee a couple weeks.

The payoff (profit, or time saved), therefore, isn't immediate: the payoff is months later, when the new hire is up to speed and is able to work more-or-less independently.

Oh yes, apart from getting them to ask ad hoc questions, you should do code reviews/inspections of everything they finish. When they say they're ready for a code review, your first question might be "Have you tested this?" In your code review you look for obvious bugs. The ideal clarity to aim for is that code is complete not when "it has no obvious bugs" but when "it obviously has no bugs".

Your code review criticisms should be either:

• Must fix immediately, before check-in (e.g. a bug, doesn't meet requirements, or unmaintainable)
• Optional (e.g. "I see what you've done, and it's not a bug, but FYI I would have done it this way")

Answer 15

Learn to Teach

You are a computer programmer not a teacher, however, there was a time when you were not a computer programmer. Just as you learnt how to do the former you can learn how to do the latter.

Talk to your company about providing education to you in how to educate others.