10 resources for Sales Engineering managers
An operating handbook, a set of questions and a peer community help with different problems. The useful choice depends on what your team needs to change.
For Sales Engineering managers, GitLab's public handbook is a useful reference for recurring management work, while Lara Hogan's questions help prepare individual conversations. MOCHA and DACI address a different problem: making responsibility clear when work or decisions involve several people.
The selection here covers ten different management needs. Each resource has public material you can inspect before committing to a course, membership or new team routine. The question is what it helps you do, where it falls short, and whether that matches the problem in your team.
1. GitLab SA Manager Operating Rhythm
GitLab's SA Manager Operating Rhythm is a public example of how one company divides management work across weekly, monthly and longer cycles. It covers customer engagements alongside individual development, practice and recognition. That makes it useful for reviewing a calendar crowded with deals: which responsibilities have regular attention, and which depend on something going wrong first?
Read it as a reference from GitLab's organisation. Its targets, systems and approval processes belong to that business. A smaller SE team may need a much lighter routine. Borrow a practice because it addresses a gap you can name; copying the whole calendar would add obligations before you know whether they help.
2. Questions for our first 1:1
Lara Hogan's questions help a manager understand how an individual wants support, feedback and recognition. They also ask what makes a 1:1 useful to that person. An SE who needs help preparing a difficult customer conversation may need something different from a colleague thinking about their next role.
Hogan presents these as starting points with room for follow-up, including in an established relationship. Give the answer time to change the conversation. If someone says they need clearer priorities, returning immediately to opportunity status leaves that need unresolved. The questions open a discussion; agreeing what support you will provide is still your job.
3. Atlassian Sparring
Atlassian's Sparring play structures peer feedback on a draft or idea. The presenter explains the audience, purpose and areas where feedback is needed; colleagues review the work before discussing their suggestions. For an SE team, a demo storyline or evaluation plan could be the draft.
Give reviewers the customer's situation as well as the material. Otherwise they can judge presentation polish while missing whether the work answers the customer's question. Sparring helps improve a piece of work before it is used. It cannot establish what the customer values if the team has yet to find that out.
4. The Management Center's MOCHA
MOCHA separates the person driving a project from the people managing, helping, advising and approving it. The Management Center's guide explains the roles and how they can apply within a larger project. It is useful when several people contribute but nobody is clearly responsible for getting the work finished.
For example, a shared demo environment may involve an SE, Product and Operations. Naming an owner only helps if the participants agree to their roles and have time to do the work. The guide explicitly calls for that conversation. Use MOCHA to settle who will carry the work, including the coordination, before accepting the project as staffed.
5. Atlassian DACI
DACI clarifies who drives a decision, who makes it, who contributes expertise and who needs to know the outcome. That differs from assigning the work itself. A cross-functional group can know who is preparing an evaluation and still be unclear about who can approve its scope.
The play asks for the decision's context, relevant information, options and decision factors. Use those parts before assigning the final call to someone. For an evaluation, the discussion might include the customer commitment required and what other work would be delayed. Clear authority helps a decision happen; the reasoning still has to justify it.
6. Google re:Work team effectiveness guide
Google's team effectiveness guide gives managers questions about how people work together, including whether they can raise problems and understand what is expected of them. It can help open a team discussion when delivery looks orderly but concerns surface only in private.
The guide reports Google's own research and describes ways teams discussed their needs. Its findings are a starting point for investigation in your team, with the limitation Google itself states: what mattered in its study may differ elsewhere. Ask for examples of what happens when someone questions a plan. A reassuring survey score alone will not explain how the team handles disagreement.
7. Mastering Technical Sales leadership curriculum
The Mastering Technical Sales leadership curriculum is a public syllabus for role-specific workshops. It distinguishes topics such as coaching, managing time and the SE manager's role in customer engagements. That helps when a development request is still as broad as becoming a better manager.
Use the descriptions to narrow the behaviour that needs work. Does the manager need to give better coaching, or stop taking over work their SEs should handle? Those lead to different learning needs. The PDF describes commercial training; it does not give you the workshops themselves or demonstrate that a course will solve your team's problem.
8. We The Sales Engineers
We The Sales Engineers publishes conversations with presales practitioners alongside other SE material. Its public episode introductions include leadership development and the less visible parts of SE management. It is an entry point for finding how another practitioner describes a difficulty you are facing.
Choose a conversation for the question it can help you explore. When a guest describes a change that worked, ask what in their product, sales cycle or team made it possible. A practitioner's account can suggest an option to test. It does not establish that the same change will work in your organisation. The site's separate coaching offer is a different commitment from reading or listening.
9. NASA After Action Review
NASA's After Action Review guide compares what was intended with what happened, then asks what to repeat or change. NASA also describes its Pause and Learn adaptation for use during a project. In an SE team, this can structure a review after a customer evaluation or an internal initiative.
Agree on the events before explaining the result. If an evaluation ran late, distinguish a changed customer requirement from work the team underestimated. The next action depends on that difference. NASA explicitly treats the review as a learning event, separate from personal performance evaluation. Keep that purpose clear if you want people to discuss their decisions openly.
10. PreSales Collective
PreSales Collective provides a peer community, events and learning resources for presales professionals. Its public membership information distinguishes free access from paid options, including a leadership community. It is relevant when the missing input is another manager's perspective on a problem that is hard to discuss inside your own reporting line.
A useful peer question explains the decision and its constraints while protecting customer and employee information. Ask what others tried and under which conditions, then compare those conditions with yours. Access to a community gives you a place to ask; it does not guarantee an answer, confidentiality or the quality of a recommendation. Check the access and participation terms before joining.
Sources
- GitLab SA Manager Operating Rhythm
- Questions for our first 1:1
- Atlassian Sparring
- The Management Center’s MOCHA
- Atlassian DACI
- Google re:Work team effectiveness guide
- Mastering Technical Sales leadership curriculum
- We The Sales Engineers
- NASA After Action Review
- PreSales Collective
Sources checked on 28 October 2026.