Implementing Team Training that Works
So you just read my last article (Developing Team Documentation that Matters), and you’re thinking “cool story bro, but I bet the documentation is outdated in a few months.” And in most organizations, you’re probably right. But in this article, I will discuss a few options to keep your documentation squared away, your material written in “one voice,” and your analysts on the same page going forward. It’s time to talk about team training.
Every team has unbelievable newcomer training, right? Okay, probably not. I promise that building an effective in-house training program is an easy lift once you have developed basic, repeatable processes. In this article, I will discuss three training schedules that I have seen work well together:
Initial Analyst Training
Weekly Analyst Exchange
Annual Reset
Initial Training
So the first step in creating an amazing team is to provide them with baseline training using the documentation and slides we produced in my last article. This training should look like 2–3 hours of slides a day that discuss the theory of your team’s work (e.g. Why we write Medium articles?), as well as training on how to do the work (e.g. here are screenshots of us writing a Medium article). I recommend presenting a block of theory immediately followed by a block of task-specific steps. For example, when I teach threat analysts about whois, DNS, and pDNS theory, I follow that block with a session going through the tools we use to research those items. These two blocks of slides are reinforced during the practical exercises by assigning the analysts a few domains, IPs, and URLs that require enrichment and pivoting for existing work products.
After a few hours of death-by-PowerPoint, new team members can be given real assignments to work through under the watchful eye of a senior analyst. Depending on how safe the work is (e.g. just writing a draft article compared to working an incident ticket in a SOC), the senior analyst may have time to check their emails and conduct a little routine business of their own. Leaders will have to assess how free-range their new people can be during training based on the type of work they do. The idea here is to give them real work to practice their new skills while a senior analyst is available to answer questions and provide support.
To ensure that new analysts know enough to get started on work on their first or second day of training, leaders should balance the material with basic concepts scheduled upfront. For example, day one of our fictitious training focuses on how to create a Medium account and how to use Grammarly to review a draft before submitting it for a senior review. This is enough for a new writer to take a stab at producing draft content. Day two or three may cover the review process and advanced formatting techniques during the slide portion, and then the practical exercise phase reviews the article that was drafted on the first and second day of training. You can begin to see how this training is iterative (teach draft, practice draft | teach review, practice review) while remaining productive — the training is using actual work material that needs to be completed rather than throwaway training material.
So that’s how I recommend handling training for new team members. Let’s look at training for continued proficiency and maturity.
Weekly Analyst Exchange
In several teams, I have successfully used weekly analyst exchanges to ensure that all team members are trained to the same standard and that processes are continuing to mature. In fact, this practice really started when I was a young Army Joe, and it was called Sergeant’s Time Training. The concept is to retrain common tasks to the documented standard.
The reason we retrain existing processes is to reiterate our baseline of team knowledge. You may have one or two analysts that work on special projects so often that they haven’t touched the routine work in months. Or your team is split into separate functions, and this method ensures that analysts receive some exposure to the other team’s work. Even if everyone is touching the same process every day, it is likely that some analysts have deviated and matured beyond the baseline standard. This retraining session is a perfect place to demonstrate new capabilities and raise the baseline to a new standard.
In the weekly training sessions, we start by covering the existing work instructions and Standards & Guidance documents before walking through one or two examples. We discuss what works, what doesn’t, and any new methods that our analysts found to improve our process and outputs. This first part normally takes 1–1.5 hours.
Just remember to update the documentation and walk through the new material one time before moving on to the next part of the session. This ensures that the team’s documents are fresh and relevant. There’s also the added benefit of enforcing the “one voice” concept as the entire team is part of the development and review process.
PRO TIP: The measure of success for the first half of training is validated documentation.
You may be interested in adding the requirement that all analysts “test out” to show they grasped the material. Don’t do this. It will kill the culture of an analyst exchange.
The second part of each training session is an open discussion geared towards analytical exercises (e.g. “how can we look at our existing datasets to identify new trends?”) or demonstrating interesting capabilities that aren’t part of routine work (e.g. “check out this formula I use in Excel to write indicator descriptions using the whois API results in bulk”).
PRO TIP: The only measure of success for this phase of training is that a single analyst learned something new. That’s it.
Again, the benefits of weekly analyst exchanges include:
Cross-training all analysts to a documented standard prevents a single point of failure
Team documentation remains fresh and relevant
Team and process maturity continually grows
Improved proficiency of team members reduces their overall level of effort when completing tasks (think: sharpen your axe every day)
SIDEBAR: If you’re unfamiliar with the theory of sharpening your axe, here is one version of the story.
Training Culture
Up front, set the culture that the training sessions are an open-discussion culture. If this is new analyst training, a bit more structure is required to keep the sessions on track and to ensure that all new analysts are trained to the same baseline. If the trainees are existing analysts in the team, ensure that they understand that injecting questions and comments is encouraged. The host of the training may want to play devil’s advocate a bit and challenge the team to think of better ways to do the same task.
In team training — not initial analyst training — you should level-set that this is a working group format and that all ideas are on the table. This encourages wild ideas and “what if we had this other tool” type conversations. The trainer should encourage these open discussions and save all decision-making until the end of the meeting. Shutting down the “impossible” too early may also stifle the possible. The intent of this training is to grow and mature the team. You cannot do this if the culture is “they’d never let us do that.” A good way to push this open-minded model is to have the trainer ask a lot of “why” questions. For example, “why do we do this process?” or “why do we do this step before this step?”
The measure of success is that all team members are comfortable talking about possible ways to improve team processes and capabilities.
Seriously think back to all of the times that you have been told “no” at work. Then consider, of those times, how many of those actually came from the appropriate decision maker and how many were shot down by teammates that had zero authority. DON’T GET STUCK IN A “NO” CULTURE.
Finding Time to Train
You’re probably thinking that this sounds like a major hindrance to daily ops and it honestly can be if it isn’t managed correctly. In reality, my old team managed our training cycles well enough that we actually had spikes in productivity during the weeks when we shut down ops for full-team retraining. We literally cleared the schedules of 20 analysts and made their place of duty the training room. But we used real-world material, and we drafted actual products as our training exercises. By the end of the week, we had:
Published more products than any previous weeks
Cross-trained and retrained our entire team to a baseline standard
Updated our training material, work instructions, and Standards & Guidance documentation
Improved our team cohesiveness and morale
Increased collaboration across shifts
Annual Training
This leads me to my last recommendation: annual training. I know that this is a radical idea, but I strongly recommend shutting down the team for a week of annual training. In these sessions, the whole team goes through the new analyst training discussed above, along with covering any advanced training that needs to be addressed. It is important to stress here that the team is training with real-world data, so operations are not put on hold. The only thing really getting “shut down” during this period is clearing everyone’s schedule of meetings. If managed correctly, operations will see a boost in productivity and all of the other benefits I listed in the Finding Time to Train section.
Now you’re thinking, cool story, but I manage a SOC and we can’t follow this at all. Let me present one last idea: Training in an Ops environment. Quite simply, you may have to run this training from the SOC floor. You can change the input on one of the wall TVs to present the slides and provide the training from the front of the room. The analysts can continue to work on assignments and the leaders will just have to work a bit extra to ensure that each analyst has an opportunity to work through each process. It’s not ideal- but not providing task-specific training is the greatest offense in my book.
That’s my approach to team training for analysts. I would love to hear your feedback, suggestions, and questions.