Experienced Analysts

1. Post in the thread that you’re available if the analyst needs any help.
2. If they don’t reach out with their plan of attack within the first hour, tag them in the thread and ask.
3. Make sure that their plan of attack makes sense, and carefully review how the paths they’ll work on impact the outline. Some potential issues:
   1. Claire doesn’t fully understand our project types, while the analysts aren’t experts at scoping. It may include several different questions in one path, and the analyst may feel obligated to follow, which will impact comprehensiveness. E.g., if the first question offers trends and drivers, and the analyst plans to focus on it, make sure they’re able to provide at least 2-3 trends and 2-3 drivers in three hours.
   2. Paths proposed by Claire often overlap. Be careful not to scope what was already provided in the first sprint.
   3. Sometimes, paths may be dependent on each other, or we may save research hours by starting with a specific one.
4. Write the outline as soon as possible. Don’t leave it for the next RM unless the circumstances are special.
   1. It isn’t efficient for two different people to familiarize themselves with all the context. Since our outlines are currently high-level, if you already have the context, it is much faster to leave the PNS in the thread.
5. If the analyst reaches out and asks for help, make sure to engage in the research/finding solutions, as opposed to providing generic ideas.
6. Encourage the analyst to tag you before they submit, especially for High Prio projects. The earlier you catch the issues, the better.
7. Good practice #1: If the request is tricky, provide your ideas for research when discussing the plan of attack and/or at least do a midpoint check to make sure the analyst is on the right track.
8. Good practice #2: If the day is slow, you can dedicate more time to the collaboration and check in with the analyst to make sure they’re on track with the research.
9. Good practice #3: Analysts may have projects without timers or may take some time before starting to work on them, so the RM who originally claimed the thread may not be around when they are ready to collaborate. This makes it difficult to execute #2. If you see a thread with no discussion that has been there for hours, and you have the bandwidth, proactively ask the analyst to share their research approach/plan for the follow-up.

New Analysts

New analysts are struggling with the lack of exact RCs like previous groups had. This seems to be the cause of much of their confusion. It will take some time for them to start thinking in RCs that are clear and effective.

<aside> <img src="/icons/exclamation-mark-double_blue.svg" alt="/icons/exclamation-mark-double_blue.svg" width="40px" /> Note: While this appears time-consuming, it is much easier and faster to catch and correct the issues early on than to do partial (during QA checks)/full revisions. It is understood that if we’re really busy, we may not be able to follow each step.

</aside>

1. Start with sending them the link to the Teammate Cheat Sheet and remind them that they’re required to follow it.
2. Ask about their plan of attack and review it thoroughly. Do not wait for them to share it with you.
   1. They don’t have the experience to realize that the path they want to start with may be dependent on another or that what Claire put in one step is actually three different paths. It may be that we’ll need to correct their approach.
   2. Make sure they know that, if possible, they should follow guidelines for a common project type. Verify their choice of project type.
   3. Many times, asking the analyst HOW they plan to solve the question is very beneficial. This keeps us from wasting everyone’s time.
3. Ask to check in again after they complete a small portion of the request (e.g., a few rows of the spreadsheet, one insight/trend, etc.). Tag them in the thread and/or check the editor if they’re quiet. Provide feedback.
   1. If we don’t catch issues early on, it’s very possible that the analyst will waste hours going in the wrong direction. Since we don’t have 24-hour RM coverage, they may also submit when no RM is online, and we’ll need to revise their work.
   2. Ideally, if circumstances allow, the feedback should be detailed. If we mention any issues with the format, writing, robustness, linking to highlight, etc., we’ll save a lot of time both for the analyst and ourselves.
4. If their approach is off:
   1. Explain precisely what they’re doing wrong and how to fix it.
   2. If possible/relevant, share any strategies you would use to complete the project (being as specific as possible).
   3. Provide them with 1-2 sample findings and/or a few sources to get them going and show the direction.
   4. Stay with them for a bit to make sure they’re on the right track. If it seems they can’t handle the project, consider offering it to a more experienced analyst. Let @Lisa know how long they worked on it so we can handle comp. If we are not on shift, let the analyst know they will hear from us when we return.
5. If their approach is correct or if they fixed it after collaboration, let them know you’ll be available if they have any further questions and that they should reach out to you or another RM on shift for a final look before submitting.
6. If, at some point, they are running out of time and aren’t done, consider reassigning the request with a new timer.