Deliberate Practice

They say that practice makes perfect. While it’s true that practice is important to hone one’s skills, it’s how you actually do that practice that matters. Deliberate Practice is a particular way of practicing that is persistant and intense. When one practices deliberately, they are stretching beyond their normal comfort level and they are focusing on a particular piece of their routine or demonstration to work on with a specific goal of improving performance.

Similar to athletes breaking down specific parts of their movements, Solutions Architects should be focusing on specific parts of their demonstrations to improve them. As opposed to working on the entire swing all at once, a baseball or cricket player may work on how their hips are positioned or where their hands are on the bat during each swing. Breaking down your routine into areas you can focus on is an important part of practicing deliberately.

Deliberate Practice is not an easy thing to do. It requires you to get out of your comfort level and try new ways to improve. If you keep practicing the same way over and over, you’ll never improve.

Once you have broken down your routine and feel good about what you are doing, it’s important to solicit feedback on your performance. Feedback is how we grow and learn. Feedback, both receiving and giving, is extremely important in deliberate practice. If you have a new way of attempting something, it’s extremely important to contact your team members and perform it for them. Let them see what you’ve done and offer you feedback. If you are asked to provide feedback, please take it seriously. Feedback of “that looks great!” or “nice job” is friendly, but not the most useful. Try to find specific things the presenter did that stood out or could be improved.

Techniques That Can Help

Breaking down a demonstration into manageable areas may not be the easiest thing to do, so here are some exercises that GitLab Solution Architects can work on:

Lightning Talks

Finding a topic that you are unfamiliar with and putting some time into understanding it can be a great way to improve. A Lightning Talk is a way of delivering this information in a clear and concise manner. Lightning Talks should be no more than five minutes long and should only use slides to get your point accross. When performing a Lightning Talk, there should be no need to go into the actual application to show what you are discussing. Use the minimal slides you have to get quickly to your point and explain how it can be beneficial to GitLab users. Five minutes goes very fast when addressing a group or performing a discussion. Lightning Talks can also help you prepare for how best to deliver your message. If you only have so much time, you want to make sure the words you use are the meaningful ones that get your point across.

GitLab Solutions Architects should feel comfortable performing Lightning Talks in front of their peers

Tips:

• Give a quick intro to who you are and why you are discussing this topic today
• A five minute Lightning Talk should have 10 slides at the most
• Set a scenario, but get to your point quickly
• Do not try to cover more than one topic in Lightning Talk
• Begin your wrap-up with about one minute remaning so you can recap
• Solicit feedback from your peers and/or manager

Examples:

• SAST for Helm Charts
• Open Source MR Process
• Parallel Matrix in GitLab CI

Demo Jam

Similar to lightning talks, Demo Jam is practiced amongst the Commercial SA Team as a safe place to continously practice showcasing features, managing objections, and improving storytelling.

Objection Handling Workshops

To ensure that GitLab Solution Architects are as best prepared as they can be, the practice of Objection Handling is something we would love all SA’s to be well versed in. The SA Handbook has an entire page devoted to effective Objection Handling.

Feature Fridays

This is a fun practice where a Solutions Architect Manager will select up to 3 SA’s to pick an interesting feature they like most and have them do a quick Slack message about it. As the name implies, the SA should post these on Friday mornings. Selections should be done on a Wednesday so the SA’s have time to think about it and put together a simple summary. SA’s can post the message in the #customer-success Slack channel. These should be pretty minimal, but at the very least, the summary should include the name of the feature, why they like it and a link to the documentation. If there’s a project that shows off this feature, SA’s can feel free to include that as well.

• Example:

“I’m a huge fan of our DAST scanning. Being able to scan a working application from the outside provides customers with tons of value. Customers can see if there are any vulnerabilities before ever deploying to production. In our 13.3 release, users can even scan On-Demand!”

Discovery Facilitation Practice

This is a facilitation session where Solutions Architects will be assigned a random discovery scenario with a stakeholder. They will have 20 mins to do discovery & achieve the end outcome. Other attendees will provide feedbacck using the facilitation feedback rubric. The selected SAs will have a week of lead time to prepare for the discovery session.

• Example: Enterprise US Solutions Architecture Deliberate Practice

Peer Reviews

An SA peer review involves a collaborative exchange among members of the same SA team regarding ongoing opportunities. The primary SA and other team members engage in discussions aimed at enhancing teamwork and achieving improved outcomes. This entails sharing insights, best practices, and strategies for closing opportunities more effectively and efficiently. It provides a supportive environment for evaluating opportunities in progress, drawing lessons from colleagues’ experiences, and exchanging valuable insights through questions and suggestions.

The benefits of frequent peer review sessions include:

1. Quality Enhancement: Peer review sessions help identify potential issues, errors, or gaps in pre-sales collateral materials and processes, ensuring that the value proposition and technical opportunity plans are of the highest quality before they reach the customer.
2. Diverse Perspectives: Different team members bring unique viewpoints and expertise to the table. Peer reviews encourage the sharing of diverse perspectives, leading to well-rounded and comprehensive pre-sales strategies.
3. Knowledge Sharing: Peer reviews facilitate the sharing of knowledge, best practices, and lessons learned. Team members can learn from each other’s experiences, contributing to continuous improvement.
4. Improved Accuracy: Through rigorous examination, peer review sessions can help catch inaccuracies, inconsistencies, or misinterpretations in information shared with customers.
5. Enhanced Collaboration: Collaborative peer reviews foster teamwork and open communication among team members. They encourage open discussions, idea sharing, and joint problem-solving, leading to stronger collaboration within the pre-sales team.
6. Efficiency: Catching mistakes early in the pre-sales process prevents time-consuming and costly corrections later. Peer reviews streamline the process by addressing issues promptly, resulting in more efficient workflows.
7. Client-Centric Approach: Peer reviews help ensure that the technical opportunity plans are tailored to the client’s needs and preferences. This client-centric approach increases the likelihood of delivering a compelling and relevant value proposition.
8. Skill Development: Participating in peer review sessions hones team members’ analytical and critical thinking skills. Constructive feedback and discussions contribute to professional growth and development.
9. Confidence Boost: Knowing that the approach and the action plan have undergone rigorous peer review instills confidence in the team’s work and gives them assurance when presenting to prospects and customers.

Process

• Process DRI (rotated monthly or quarterly )
  • Ensures that every session has one or multiple volunteers to present an opportunity for review. If no volunteers are identified, the process DRI is responsible for cancelling the meetong
  • Sends a reminder to team members BEFORE the meeting to ensure they review what has been filled in
• Presenting SA
  • Creates a copy and fills out the SA Peer Review template document before the session. This should not be a heavy lift preparation and the presenting SA is expected to spend max. 10-15 minutes on this. The document should incude:
    • High level description of the account and opportunity;
    • Technical Opportunity Plan; Timeline; Actions already executed or planned;
    • Links to additional information (SFDC, slide decks, opportunity / strategy / success plans, etc.)
• Attending SAs
  • Review meeting notes / template beforehand
  • Ask questions & provide suggestions during the session. E.g.:
    • Did you consider suggesting Scan Result Policies?
    • Your running notes have great info about the tech stack, how were you able to find that?

Choosing the right opportunity

A good opportunity for a peer review process should meet following requirements:

• Any ongoing opportunity that would benefit from peers input
• Accounts with growth potential
• Technical discovery has already been completed
• Requieres diverse perspective or ideas to unblock the deal