From “Founding Sales: Sales for founders (and others) in first-time sales roles” by Pete Kazanjy.  

This is a reference architecture for an early stage startup internal meeting cadence, including what meetings to have, with whom, at what cadence, covering which topics, and specifically not covering which topics. It goes from one-on-ones, to team meetings, to all-hands, and covers meetings for Engineering, Sales, and Customer Success. It’s patterned off of the meeting cadence we had at TalentBin, and a number of the companies I advise / have invested in use it as well.

Obviously there are variations to this, and this framework can be extended beyond to larger / later stage organizations. Please use this as a jumping off point and hack on this to make it your own. But the hope is that by providing a thought framework for founders and other early stage staff to use in their own context, missteps can be avoided, and you can have more success, faster, in your own organizations.

Pretty please report bugs to petekazanjy@stanfordalumni.org! Gracias!

Introduction

Meeting Metadata

Engineering

Sales

Customer Success

Whole-Org Meetings

Cross-Executive Meetings

“Which use cases are handled by which meeting?”

Early Stage Startup Meeting Cadence Reference Architecture

The goal of this document is to map out a basic meeting cadence for early stage startups. You might say “Wait a minute?! Meetings are those things that waste time and are for big companies!” Au contraire, buddy. Poorly run meetings waste time.

Meetings are for richly communicating information, and receiving it. For ensuring that the things the organization is supposed to be doing is being done, that people within the organization understand what the larger goal is, their place in it, what they should be doing to proceed towards that, and to raise issues if they see divergence there.

If you don’t do them, the core needs will still be there, and they’ll just get served other ways. If you don’t have private venues for surfacing issues, they will happen in backchannel conversations in ways that erode morale. If you don’t have a means to communicate, and reiterate, top priorities, then people will work on whatever is in front of them, or things they like, versus things that organization needs. If people don’t know when information will be shared with them, they will assume you’re hiding it from them. Fix all of this with a thoughtful meeting cadence, wherein certain meetings have a certain purpose (and stated anti-purposes), and proactively handle these information distribution and feedback solicitation needs.

Don’t skimp on the meetings. And as a founder, guess what: you’re a manager. So get used to it. You’re going to have a lot of these. You are an information router, and communicating and extracting that via rich, face-to-face communication is often the best way to do this.

And no, a company-wide Slack channel does not count.

• How implement them: Meetings should have a stated purpose, a stated set of attendees, a format (which supports the purpose), a specified length, and a cadence to them.
  
  The best way to do this is to use Calendar invites, setting the recurring time frame to what the recurring period is specified to be, inviting the relevant attendees (those who are required - avoid “optional” as much as possible. If they’re optional, they’re likely not needed, and should be doing other things), and putting the specific format and recurring agenda in the meeting description.
  
  Like this:
  
  
  
  Or this:
  
  
  
  Or this:
  
  
  
  Breadth of attendance is where you can be most efficient with meetings. Are most of the attendees sitting around not receiving information or contributing information in the meeting? They’re probably not required, think about splitting that meeting into a bunch of individual ones. Sprint planning or tactical status meetings can be like this - why should the rest of the engineering staff sit there when the product lead and a given engineer are discussing her specific feature? There may be some benefit there, but nothing that isn’t already handled in the larger dev team meeting. So make those individual meetings between product lead and individual engineers.
  
  Cadencing serves the purpose of letting staff know that if something doesn’t get covered this time, it can be put on the agenda for next time. It also ensures that staff knows that what was discussed and agreed in this meeting will indeed by checked on next meeting - so promises can’t be empty. Cadence also needs to be appropriate to the attendee base, depth of the meeting, and purpose. There is no need for weekly all-hands. You’re likely handling things in that meeting that should handled in others. One-on-ones done monthly is probably too infrequent - you run the risk of staff irritation boiling over if they don’t have a release valve.
  
  Time frame should be constrained to what is needed, as well. No sprawl. If have more content than can be handled in the meeting, prioritize the content, and then save the unhandled stuff for the next one. Either have a tracking document to record what was covered, and action items, or actively put the next content in the next meeting’s Description field. If there is special content that is required, can it be handled in an email? If none of that will work (it better be an emergency), put another meeting on the calendar to address that specific topic.
  
  Timing of meetings is important to pay attention to. Scheduling team meetings during lunch (one of the benefits of bringing lunch into the office) makes it such that you don’t stomp on productive time during the rest of the day. Otherwise, meetings at the “edges” of the day - either at the very beginning, to compel a sprinter’s start, or at the end of the day, when people are burned from their day of work and can use a break.

Content and Format needs to be explicitly set. If there is lack of clarity as to what this meeting is for and what content is to be covered, you will get creep, which will dilute the purpose of the meeting, and keep you from achieving the goal of the meeting. The owner needs to be the goal keeper of keeping the meeting on track, and not diverging from its purpose.

Owner: There needs to be an explicit owner of the meeting who is responsible for adhering to the agenda, keeping the meeting on track, and on timeline, and if things are diverging from agenda, cutting it off and providing an outlet for that other content (Can it be handled outside the meeting? In email? At the next meeting? At another, more appropriate venue?)

• What are the type of meetings you should have in your early stage org? The below is a proposed meeting framework for a small company that has less than two layers of management. That is, a founder who leads either Product/Engineering or Sales, and a layer of management below, in the form of functional owners (like a Sales Lead, a Product Lead, a CS Lead)

• Product and Engineering
  

• Dev Status

• Purpose: Purpose of this is a venue for engineering to (briefly) share with each other what they worked on last week, what they’re prioritizing this week, and to have a shared space for camaraderie and interaction, with the intent of ensuring engineers know what each other are working to allow for raising of concerns or making suggestions on other engineers’ projects. Also a venue to potentially bring up questions that are relevant to the whole group (not personal items). A place to share and have a sense of what is happening, and have shared accountability through transparency.
• Anti-purpose: Not a product planning meeting. Not a tactical status meeting to go through Pivotal ticket by Pivotal ticket.
• Attendees: All engineering team and product lead.
• Format: Start with brief status. Round table of each engineer spending two minutes characterizing what they did last week and what they're focused on this week, allowing for engineering feedback. Followed by “wins and learnings”. What was both a professional and a personal win from last week? What was a learning? (Defined as “Man, I wish I knew this before, because learning it was less than fun, but I’m sharing with you all so you don’t have to pay the same price for the learning!”).
• Cadence and Timing: Once a week. Beginning of week. Ideally Monday.
• Length: An hour, at lunch.
• Owner: Either product or engineering leader (whoever engineers report to).
  

• Tactical Dev Status

• Purpose: A one-on-one, or small-team tactical status meeting to track progress against assigned features and bugs, and ensure that prioritization of Pivotal tickets is being followed.
• Anti-purpose: Not a meeting for talking about personal issues, talking about future features, etc.
• Attendees: Product lead (or Engineering Lead), whoever is responsible for tracking progress towards feature completion, and managing engineering resources.
• Format: Product lead working with engineer to discuss what was worked on last week, what’s being prioritized this week, what was faster than expected, what slipped. Literally done side by side in Pivotal (Trello, JIRA, etc.). Outcome is what will be worked on for the ensuing week till the next meeting (at which progress will be reviewed.) Utilize a Pivotal (or equivalent) “story” to capture this week’s goals such that it can be referred to throughout the week, and come next week, be indexed against to see achievement or shortfall.
• Cadence and Timing: Once a week. Ideally at “edges” of the day (morning or later afternoon), to avoid work time disruption.
• Length: 5 - 15 minutes. Depending on how much to go through. As soon as done, stop meeting.
• Owner: Product owner or tech lead.
  

• Sprint Initiation

• Purpose: To define and negotiate what will be worked on over the next sprint for a given engineer.
• Anti-purpose: Not a personal one-on-one.
• Attendees: Product lead and engineer who will be working on the feature (or set of bugs)
• Format: Discussion of specification of new feature. Discussion around prioritization, and why this is important for the business right now. Discussion of prioritization of what engineer might want to work on (as may change prioritization of features based on engineering appetite). Discussion around the goal of the feature. Discussion of staging (what in Sprint 1, what in Sprint 2). Or, in the case of a “bug sprint” (a sprint focused purely on bug fixing), discussion of the bugs or tech debt to be addressed, why they are a priority for the business (related to usage data / sales pressures / engineering enablement, etc.), and what the business goals are of fixing the bugs in question.
• Cadence and Timing:  One-off when an engineer finishes prior sprint. Can be mid-day.
• Length: 30 minutes (Maybe 60 minutes).  Depends on how deep the conversation needs to be. The tactical status meeting is weekly, and handles any issues that pop up in between (as does IM / email / walking by the desk.)
• Owner: Product lead
  

• One on ones

• Purpose: Solely for direct manager to proactively extract issues as viewed by the engineer, and share information in a private setting. With major emphasis on “usability engineering” on behalf of the manager.
• Anti-purpose: This is not a status meeting. This is not a planning meeting. Those are handled other places. Focus purely on engineer issues and needs and career development discussion.
• Attendees: Direct manager and engineer.
• Format: Have a set of items to go through, every time. I like the format “What do you need from me?” (As in, what needs to be better?) “What do I need from you?” (As in, how are you performing, and what changes do I need?”), and “What do you need to know?”. As related to the former, focus deeply on issue extraction from staff who may be reticent to share issues. Ask “Are there any flags?” “What could be better” in 10 different ways. If still no answer, dive into specific examples “How do you think team cohesion is going?” or “How are you feeling about <feature X> we’re working on.” “What do you need to know” should focus on “What information do I need to share with you with commentary that may not be suitable for a public setting”, allowing the manager to candidly discuss information and have a richer give and take. By always following a format, it will be a forcing function to surface yellow flags, and ensure you don’t have blowups and surprises. Focus deeply on extracting issues. If you have observed things in the wild that you feel are underlying, unstated issues, bring them up.
• Cadence and Timing: Every two weeks. Ideally have all meetings on the same day (if team is larger, have them on consecutive days). If there is a topic that needs to be addressed privately with team members in parallel, one on one, having them all on the same day, or quickly together, will allow you the megaphone to do this. Do NOT skip these. If you have to skip, do NOT skip. Move the meeting to later that day. Or the next day. DO NOT SKIP THESE. It will bite you in the ass.
• Length: 30 minutes
• Owner: Product lead or engineering lead (whoever is the engineer’s manager.)
  

• Sales / Sales Ops: Sales has a faster, more frequent tempo, along with a set of actions that requires more instrumentation and accountability than engineering. As such, while some of the meetings will have overlap, there are others that are handled differently and others that exist where they did not in engineering.
  

• Sales Stand ups

• Purpose: To provide a checkpoint to the day, promote shared learning, and promote transparent accountability. Quick and up tempo to help maintain in-day tempo.
• Anti-purpose: Not for exhaustive rehashing all work done, questioning strategy, etc.
• Attendees: Entire sales team.
• Format: <30 seconds per person on key metrics that were achieved in the prior interval - Demos done, Calls made, emails sent. Show up to the meeting with the numbers, and put them on a shared whiteboard dashboard as a means of shared transparency. Share any key items “of note” (would be exciting wins, could be big flubs to share with others to avoid.) If someone is out of the office (working), they need to dial in for it. If they are occupied at the time (try not to be) with a demo, traveling, working from home or such, numbers and comments should be emailed to team ahead of time.
• Cadence and Timing: Twice a day. Noon just before lunch and 5:00pm.
• Length: <10 minutes.
• Owner: Sales lead.
  

• Sales Team meeting

• Purpose: To review prior week’s metrics, outperformance or shortfalls, promote team shared accountability and transparency, and provide information and solicit feedback as regards product to date and product future, and customer success.
• Anti-purpose: Not a roundtable, ideation session. Not a group bitch session.
• Attendees: Entire sales team. Product leadership representative, customer success representative.
• Format: Have key team metrics that team is focusing on achieving more / less of, and start meeting by reporting on them. Demos held prior week, month to date, revenue month-to-date, etc. Have segment of meeting (5 - 10 minutes) focused on product leadership sharing what shipped last week, what is shipping this week, and soliciting product feedback. Have segment of meeting (5 minutes) for Customer Success to share information, make requests, and solicit feedback. Product and CS participation can be front-loaded so those representatives can peel off after their role is concluded. Team should go around and share a personal win and a personal learning from the prior week. Review any particular information that needs to be underscored in a group environment (which may have been emailed, previously). Are there particular new programs that are shipping? New materials for reps to be aware of? Changes to CS protocol? (Again, many of these could have been previously emailed, but may need reiteration to ensure “they stick.”) Solicit questions and feedback on the go-to-market, and issues that might impact the whole group (not personal issues.) Solicit feature requests on sales operations, marketing materials, etc. (as long as touch whole team.) If first meeting after end of month, or end of quarter, use it as a retrospective.
• Cadence and Timing: Weekly. Mondays, lunch. Bring lunch in.
• Length: 60 minutes.
• Owner: Sales leader.
  

• Pipeline meeting

• Purpose: To provide a venue for shared accountability and focused work on pipeline maintenance.
• Anti-purpose: Not a ideation, bitchfest meeting.
• Attendees: Full sales team of AEs (not SDRs)
• Format: Each seller reviews last week’s deals, and which deals will likely come in this week. Time is spent on concerted down-funnel work around pipeline maintenance (ensuring that relevant Opps are in correct stage, Closed Losting dead opps, and general pipeline.) Because this is unpleasant work that reps avoid, compel it in a group environment. And bring in pizza to make it suck less. Close meeting with reporting of activity in the meeting (Opps closed, Opps updated, contacts touched). People shouldn't miss this meeting. Or schedule demos over it. It's here to be a place to make sure work that may not otherwise get done actually gets done.
• Cadence and Timing: Weekly. Wednesday end of day. Get pizza.
• Length: 60 - 120 minutes.
• Owner: Sales leader.
  

• One on ones

• Purpose: As with engineering, the purpose of this is solely for direct manager to proactively extract issues as viewed by the rep, and share information in a private setting.
• Anti-purpose: This is not a status meeting. This is not a pipeline review. Those are handled other places. Focus purely on rep issues and needs and career development discussion.
• Attendees: Direct manager and sales rep.
• Format: As with engineering, have a set of items to go through, every time. I like the format “What do you need from me?” (As in, what needs to be better?) “What do I need from you?” (As in, how are you performing, and what changes do I need?”), and “What do you need to know?”. In the “What do I need from you” case, it’s appropriate for sales staff to review past-week, or month-to-date, quarter-to-date stats, to ensure that things are tracking appropriately. As regards information sharing, this is “What information do I need to share with you with commentary that may not be suitable for a public setting”). By always following a format, it will be a forcing function to surface this information, and ensure you don’t have blowups and surprises. Focus deeply on extracting issues. If you have observed things in the wild that you feel are underlying issues, bring them up. In sales orgs, issues typically show up in metrics, and should be discussed here.
• Cadence and Timing: Every two weeks. Ideally have all meetings on the same day (if team is larger, have them on consecutive days). If there is a topic that needs to be addressed privately with team members in parallel, one on one, having them all on the same day, or quickly together, will allow you the megaphone to do this. Do NOT skip these. If you have to skip, do NOT skip. Move the meeting to later that day. Or the next day. DO NOT SKIP THESE. It will bite you in the ass.
• Length: 30 minutes
• Owner: Sales lead (whoever is the sales rep’s manager.)
  

• Customer Success: Customer success has a tempo more like sales, and thus their meetings are more similar to sales’. The below is in the event that you have a customer success team with more than one rep, but if you simply have a single customer success individual, you still have to handle the team meeting case (for information sharing / feedback solicitation purposes).
  

• Stand ups

• Purpose: Shared activity accountability, and information sharing to maintain in-day tempo.
• Anti-purpose: Exhastive information sharing, strategy discussion, group bitch session, etc.
• Attendees: All CS staff.
• Format: Review days stats, of note items (wins, learnings)
• Cadence and Timing: Once a day, noon before lunch.
• Length: <10 minutes.
• Owner: CS Lead.
  

• Team meeting

• Purpose: Review key metrics as a group, reiterate goals, foster team camaraderie, and provide venue for information sharing between sales, product, and the Customer Success team.
• Anti-purpose: Not a roundtable, ideation session. Not a group bitch session.
• Attendees: All Customer Success staff, sales lead, product lead.
• Format: Cover prior week’s relevant performance stats, as relates to general organization execution, or particular programs that are being executed against. Have segment of meeting (5 - 10 minutes) focused on product leadership sharing what shipped last week, what is shipping this week, and soliciting product feedback. Have segment of meeting (5 minutes) for Sales to share information, make requests, and solicit feedback. Product and Sales participation can be front-loaded so those representatives can peel off after their role is concluded. Team should go around and share a personal win and a personal learning from the prior week. Review any particular information that needs to be underscored in a group environment (which may have been emailed, previously). Are there particular new programs that are shipping? New materials for reps to be aware of? Changes to CS protocol? (Again, many of these could have been previously emailed, but may need reiteration to ensure “they stick.”) Solicit questions and feedback on the go-to-market, and issues that might impact the whole group (not personal issues.) Solicit feature requests on sales operations, marketing materials, etc. (as long as touch whole team.)
• Cadence and Timing: Weekly, Mondays at lunch.
• Length: 60 minutes.
• Owner: Customer Success Lead
  

• One on ones

• Purpose: As with sales, the purpose of this is solely for direct manager to proactively extract issues as viewed by the CS rep, and share information in a private setting.
• Anti-purpose: This is not a status meeting. Those are handled other places. Focus purely on rep issues and needs and career development discussion.
• Attendees: Direct manager and CS rep.
• Format: As with sales, have a set of items to go through, every time. I like the format “What do you need from me?” (As in, what needs to be better?) “What do I need from you?” (As in, how are you performing, and what changes do I need?”), and “What do you need to know?”. In the “What do I need from you” case, it’s appropriate for CS staff to review past-week, or month-to-date, quarter-to-date stats that are CS-specific (like output numbers, quality numbers), to ensure that things are tracking appropriately. As regards information sharing, this is “What information do I need to share with you with commentary that may not be suitable for a public setting”). By always following a format, it will be a forcing function to surface this information, and ensure you don’t have blowups and surprises. Focus deeply on extracting issues. If you have observed things in the wild that you feel are underlying issues, bring them up.
• Cadence and Timing: Every two weeks. Ideally have all meetings on the same day (if team is larger, have them on consecutive days). If there is a topic that needs to be addressed privately with team members in parallel, one on one, having them all on the same day, or quickly together, will allow you the megaphone to do this. Do NOT skip these. If you have to skip, do NOT skip. Move the meeting to later that day. Or the next day. DO NOT SKIP THESE. It will bite you in the ass.
• Length: 30 minutes
• Owner: CS lead (whoever is the CS rep’s manager.)

• All

• All Hands

• Purpose: To create an environment of camaraderie and mutually accountable transparency, via sharing and reiterating strategy, reviewing metrics around successes and challenges in pursuit of that strategy, and solicit group-appropriate feedback
• Anti-purpose: An all hands is not a bitch session. It is not an ideation session.
• Attendees: The whole company.
• Format: Given the monthly timing, it is appropriate to use slides as a means by which to govern agenda and content to be shared. Monthly all hands should be framed in the context of “What are we trying to achieve” as an organization (which can change, depending on the stage of the organization), and what are the inputs that are going into that, on a per-functional team basis (Product, Sales, CS), and how are those various teams tracking against that. Preferably the owner of various organizations contribute these, focused on key metrics of importance from those orgs, new news (key hires, key programs). Reminder of organizational goals, and individual sub-goals of different organizations (particular focus in product, sales, or CS on specific short term programs).
• Cadence and Timing: Once a month, typically at the end of the day. We liked to do it on Friday at 4:30 - 5:30, and then it would roll into happy hour.
• Length: 60 minute.
• Owner: CEO, with delegates for separate parts of the meeting.
  

• Executive

• Non-Owner Executive to Owner Executive

• CEO (who is not sales lead) to Sales Lead

• Purpose: Track progress against stated sales goals, as measured via agreed key metrics.
• Anti-purpose: Not a one-on-one as relates to performance or extracting issues.
• Attendees: CEO and Sales Lead (if they are separate people)
• Format: Review key agreed metrics that track success of sales organization, their improvement, degradation. Discuss, and identify constraints that are blocking forward progress. Agree and prioritize proposed solutions to constraints, and document next steps for execution and timeline in Google Doc, for review at next meeting. At next meeting, review agreed outcomes from prior meeting, and success or divergence.
• Cadence and Timing: Every two weeks. End of day. (To avoid mid-day work disruption and occupying manager time while team is executing.)
• Length: 30-60 minutes.
• Owner: CEO (who is not sales lead)
  

• CEO (who is not engineering lead) to Engineering / Product Lead

• Purpose: Track progress against stated product goals, as measured via agreed key metrics (features shipped, bugs fixed, growth, engagement stats, app store ratings).
• Attendees: CEO and Engineering / Product  Lead (if they are separate people)
• Format: Review key agreed metrics that track success of product delivery organization, their improvement, degradation. Discuss, and identify constraints that are blocking forward progress. Agree and prioritize proposed solutions to constraints, and document next steps for execution and timeline in Google Doc, for review at next meeting. At next meeting, review agreed outcomes from prior meeting, and success or divergence.
• Cadence and Timing: Every two weeks. End of day. (To avoid mid-day work disruption and occupying manager time while team is executing.)
• Length: 30-60 minutes.
• Owner: CEO (who is not Engineering / Product lead)
  

• CEO (who is not customer success lead) to Customer Success Lead

• Purpose: Track progress against stated product goals, as measured via agreed key metrics (features shipped, bugs fixed, growth, engagement stats, app store ratings).
• Attendees: CEO and Customer Success Lead (if they are separate people)
• Format: Review key agreed metrics that track success of CS organization (NPS score, Customer Sat, tickets retired, implementations executed, key success metrics), their improvement, degradation. Discuss, and identify constraints that are blocking forward progress. Agree and prioritize proposed solutions to constraints, and document next steps for execution and timeline in Google Doc, for review at next meeting. At next meeting, review agreed outcomes from prior meeting, and success or divergence.
• Cadence and Timing: Every two weeks. End of day. (To avoid mid-day work disruption and occupying manager time while team is executing.)
• Length: 30-60 minutes.
• Owner: CEO (who is not customer success lead)
  

• How are various cases handled?
  
  One of the biggest issues in startup meetings is meeting creep, because staff don’t know which venue is appropriate for which “case”, and as such, can end up pulling topics into meetings where they aren’t relevant / appropriate / etc. You have to nip this in the bud, or else your meetings will lose efficacy. Just point out that that case is handled somewhere else - and make sure that participants feel empowered to police this, as well.
  

• When does engineering give feedback / surface issues about product and product direction? When does engineering “feel heard” regarding product?

• In one on ones, in individual Tactical Status meetings, and via emailing product leadership with feature requests and feedback.
  

• When does Sales give feedback / surface issues to product? When does sales “feel heard” regarding product?

• In one on ones to manager, who funnels it to product owner, in team meetings with product representative, and via emailing product leadership with feature requests and feedback.
  

• When does Sales give feedback to CS? (e.g., customer complaints from support or onboarding)

• In one on ones to manager, who funnels it to CS owner, in team meetings with Customer Success representative, and via emailing CS owner (cc’ing manager) with CS requests and feedback.
  

• When does CS give feedback to Sales? (e.g., poorly qualified customers being onboarded.)

• In one on ones to manager, who funnels it to sales owner, in team meetings with sales representative, and via emailing product leadership with feature requests and feedback.
  

• When does CS give feedback to product?

• In one on ones to manager, who funnels it to Product owner, in team meetings with Product representative, and via emailing CS owner (cc’ing manager) with CS requests and feedback.
  

• How does product planning happen?

• Product leader with Sales and CS leadership, aggregating all feedback from meetings and also from inbound
  

• How does product roadmap and rationale get communicated?

• Product roadmap and rationale gets communicated to engineering staff through sprint initiation meetings, and ongoing tactical status meetings. It is communicated to sales and CS organization through the product portion of weekly Sales and CS team meetings. And it is communicated more broadly to the organization through Monthly All Hands.
  

• How does Sales performance get communicated to broader organization?

• Sales performance gets communicated to broader organization through monthly all-hands, and to Product and CS leads through weekly Sales team meeting attendance.
  

• How does CS performance get communicated to broader organization?

• CS performance gets communicated to broader organization through monthly all-hands, and to Product and Sales leads through weekly Sales team meeting attendance.