This is my list of things to consider when thinking about training for a technical team, produced while discussing how we could introduce such a radical idea.

Training goals

It's useful to define what we (the business, the team, the individuals) want from training - that helps define what type of training is appropriate. Possible goals are:

• build competence - we have a job to get done, we just want to know enough to use the tools well
• maintain skillset - there are always new version of tools & software, we need to keep up to date with using them so we don't become fossils
• de-risk the future - What should we be using that we aren't using now? What will the answer to that question look like next year?
• satisfy curiosity - slightly related to the previous items, this is where the "blue sky", "leftfield", "unicorn" etc thinking is likely to occur.
• get a certificate - formal recognised certs have a prestige to them, are concrete examples of investing in people and look impressive (YMMV) on walls/email sigs.
• proof of expertise - does our team have sufficient knowledge & skills to meet some audit/corporate goals?
• benchmarking - we may want to set a min standard that we can use as a baseline for anyone in the team with a specific role.

Types of training

Training can be delivered/received in many forms. Different people learn best in different ways, so we'll probably need to provide a menu of training options, with different types of training being better for certain people and situations.

• Formal 3rd party - buy a course, probably comes with a badge/sticker/certificate (Pluralsight, Lynda, Udemy or similar)
• Formal in-house - construct/customise our own course with good trainers and decent material (expensive but potentially powerful)
• Informal in-house - chalk-and-talk in a meeting room, round a whiteboard, or maybe a specific training room. Loads of ways to do this:
  • simple presentation and chat (lots of variants, encourage trying different formats)
  • demo a thing you've built/learnt to anyone who expresses an interest
  • shared interest forums - persistent and regularly scheduled chats
  • watch video together and discuss it (masses of really good material online)
  • whiteboard scribbling (remember to take photos to record the session)
  • Pair programming - sit with someone else (hopefully with more expertise in the area). There's a Medium article on Pair Programming which covers some options.
• Books - I know, it's a crazy old school idea! What about providing a book allowance? Or building a team/dept library? Most experienced techs will have a good book list, probably with a lot of overlap between them.
• Spikes/protos/playtime - aka "Google Time". The important part being that this is kept separate from deliverable project work and has no funding/approval hoops to jump through.
• On-the-job - take a task you don't know, accept it'll take longer due to learning curve, ask lots of questions (and on the other side, expect & welcome lots of questions).
• Blogs/articles/vlogs - There's a wealth of good stuff out there including free (e.g. Spring docs/blog) and pay-for (e.g. Gary Bernhardt).
• Conferences and meetups - Some are very formal and expensive (get a proper budget freed up) e.g. JAX London, QCON. Some are just informal "bird of a feather" affairs e.g. Sheffield Geeks.
• Continuous background learning - TIL diary/posts, special interest groups, Hacker News, Stack Overflow, etc. Everyone is probably doing this already, but it needs encouraging and promoting.
• Code Katas - basically repeatedly doing a simple code exercise, doing it better each time. A big help with learning new tools and skills which you want to become subconscious/automatic eventually.

Ways to analyse training needs

How do you find out what training is needed for a particular person? The simplest (and probably the best) way is to ask them, but there are others if we're in a situation that demands something more formal.

• Self - rate yourself on a 0-4 scale (or some other really simple method)
  0 never heard of it, or heard of it but dunno anything
  1 looked at it, read a bit, maybe installed it and know what it's about
  2 used it, know the basics, know where to find out more
  3 competent, can pick it up and use it confidently
  4 expert, knows the knotty bits, can teach others, can be called on for help
• Peer - someone who knows you gives a rating and/or gap analysis
• Assessment questionaire - e.g. pluralsight TNA quiz
• Formal assessment - e.g. an exam or trial work
• Customer feedback - start doing the work, someone will tell you how you're doing

Who's the expert?

How do we tell who knows what and who needs to know more?

• Expertise/risk register. A matrix of tools/tech against the expertise level each team member has for each one. Lets us spot red flags for tech we don't really know and projects/apps that risk becoming legacy. Needs to be simple to update and visible/editable by everyone on it.
• Formal training record. Probably something for HR - but it'd also be good to have something we can share - maybe a simple "talk to X if you want to know about Y" type document. This could be a job for the expertise register.
• Informal sharing - we already have this from chatting and working together, but how do we record and enhance all those exchanges? <broken record>Set up and use persistent chat rooms</> also good use of share files, wikis, whatever low-ceremony sharing tools you have available.
• Formalised sharing - basically adding some more ceremony around the sharing tools from the informal point above and clearly show people's names. Encourage people to write up what they know as blogs or TIL notes, make recordings of chalk and talks, etc
• Share/publish our group memberships - be proud of our interests, abilities and sources of knowledge. e.g. share the history of who talks/presents in any forums or does demos or chalk-and-talk sessions.

Training Questions

Thinking about wider business/management philosophies, some of the questions to be asked of management early on in the training discussions...

• Do we prefer formal or informal training?
• Do we want to define "levels" formally, or are self/peer based metrics sufficient?
• If we're trying to achieve levels or baselines, how big a group are we including in the comparisons?
• What areas of expertise do we value/need most?
• How will we tell that it's working? What reporting/stats are needed?
• Are badges/certificates an important training output, or is the increased ability/competence/expertise in the job sufficient?
• Are the time & cash budgets already agreed & assigned? When can we start spending them?

Previous Post Next Post