Five VPE themes that come up in board meetings
As the head of engineering at a startup, you will be expected to prepare material and participate in board meetings. These are regular meetings, typically every 8-12 weeks, with the company’s board of directors. I have participated in many BoD meetings spanning numerous startups, during which I have observed a few themes that are commonly addressed by the VPE/CTO. I will outline those, map them to the startup stage and finally outline what you will likely need to present for each theme to your BoD. This will obviously vary by company, so take this with a grain of salt and adapt to your own situation.
The road to product market fit
In the early stages of a startup’s lifecycle, one of the main topics that the BoD will be keen to get updates on is customer discovery and progress towards Product Market Fit. This conversation will most likely not be led by the head of engineering, but by the CEO or head of product. It could very well be that the startup doesn’t yet have a VPE on-board. The startup is still small, perhaps under 20 employees, mostly early engineers and a few PMs, working towards proving that they have product market fit. This theme is very common at the seed and series-A stages.
The main narrative of this theme is progress towards validating product market fit, which is the primary concern of the startup in its earliest stages. During that stage, BoD meetings do not allocate a dedicated section to engineering, but seek a holistic update on the overall product and customer development progress. Below are some of the qualitative and quantitative key points I have often seen part of this narrative to the BoD.
Usage metrics are very often shared during this update. Those include app downloads, MAO/DAOs and their equivalents. The BoD is keen to understand whether your product is gaining traction or not.
Customer development interviews Qualitative data on the volume and segmentation of these interviews. Additionally, a summarization of the main themes observed from them. For example, have you identified a set of common use cases, how do those tie into market/customer segments?
Competitive overview Who do you compete with and how to plan on differentiating yourself from your competitors.
Remember, that in this early stage you are still trying to prove that you have a business, meaning that your product solves some pain ideally in a relatively large market.
Scaling
This theme is very common in the series-B and onwards stages. At this stage, the startup has proven, or has very strong conviction of product market fit, and it starts to scale. The scaling will impact engineering the most, but will also involve hiring across the entire company, often times building orgs that had yet to exist. This stage is also when a VPE is likely hired at.
Your narrative should try to answer one and only one question: are you on track to scale the engineering team? You should also share any consequences on scaling the team, especially if they are having an impact that the BoD needs to be aware of. Recall that scaling is demanding and can end up slowing your team. Reminding the team that this phenomena can happen is helpful to set the right expectations. Common data points that accompany my scaling the team narrative are below.
Hiring metrics These will include the number of engineers hired over a period of time, acceptance rate and your overall progress towards your quarterly/annual hiring goals.
Roadmap progress The BoD expects that the hiring you’ve been doing will accelerate the delivery of the roadmap - it won’t. Be that as it may, you must include a section covering where you are relative to roadmap plans. You must also be transparent if you are behind.
Organizational design Savvy boards, and trust me you want one of those, will know that the initial scaling phase will require a re-think of the organizational model. Therefore, be proactive and share your thinking on how the org will evolve over time. This goes beyond an org chart and should cover up-leveling your - likely non-existent - people programs like onboarding, career development and so on.
New product releases
This theme starts to show up in BoD at the mid-stages of a startup, series-C and beyond. The startup might have had 1 product thus far and is expanding into an adjacent market or perhaps adding new functionality to cover a broader market or use cases.
I’ve often encountered this theme when the startup decides to move from an on-premises product delivery model to a SaaS one. That decision isn’t made in a vacuum or limited to engineering. When that decision is made, it in turns implies a complete retooling of the company, especially on the GTM side. This can be a pretty stressful phase for the entire company, specifically engineering. Be prepared to be in the hot seat! Regardless of the specifics of the situation, the below are examples of data I tend to weave into my narrative for this phase.
Progress to releasing the product or “are we there yet” Honestly, there’s nothing the BoD needs from you than an honest answer to this question.
Mitigation plans I’ve yet to encounter a new product launch of substance that was risk-free or went smoothly according to plan. You should always include a section on areas of concern and how you plan to address them. You should also be upfront if the plan is at-risk, especially if the impact of the delay can have downstream impacts on the company, for example your revenue targets for the year would need to change.
Margins
In later stages, series-D and beyond, especially if the company is on track to IPO, margins and profitability will come under increased scrutiny. Engineering - more generally speaking R&D - impacts two critical profitability metrics: gross and operating margins. Your BoD and CFO, will be increasingly interested in the health of these margins and levers to improve them.
Gross margins If you’re a SaaS company or your product is sold on some hardware form-factor then you have a substantial impact on gross margins. In the case of SaaS, the infrastructure that powers your SaaS offering is considered costs of goods sold or COGS. The higher that is relative to your sales, the lower your margins and profitability. Hence optimizing your infrastructure spend - mostly cloud spend - will be paramount. And your BoD will want to know what that figure is today and how you plan on driving it down.
Operating margins Another metric that will be keenly observed is that of operating margins. The engineering organization has a substantial impact on this metric through two main cost buckets. The first is employee salaries. The second will be the infrastructure costs - cloud or on-premises - that support the product development activities. Those could be the costs for your dev environments, CI/CD, your on-premises labs and so forth.
Those metrics will start to be evaluated a few years before you IPO, because you ultimately want them to trend to comparable rates (see the table below for R&D:Sales) at the time of IPO. Another great source is from Sammy Abdullah on “R&D spend metrics in SaaS”
Quality
This is the ugliest and most challenging theme of them all. It can come up at any stage and as the heading suggests is concerned with the product quality. The overarching theme isn’t just about product quality. Quality is the tail-end of a much bigger problem that will certainly cover customer satisfaction, renewals and the overall health of the business. This is a hard one to address, especially if it’s at the BoD level.
Bug trends Even writing this on a blog post makes me feel uneasy. It’s just not a good spot to be in. But if you do find yourself here, you have to address this issue head on. Showing the volume and severity of bugs over time is helpful, not just to the BoD, but to you and your team as well. You might want to normalize this data by customer count, severity and if possible customer segment. The latter only if you suspect that most issues stem from a particular customer segment e.g enterprise vs SMB customers.
CSAT/NPS and customer feedback This data will likely be provided by your Support or Customer Success peer and will further amplify the need to fix this problem quickly. If your BoD is discussing product quality, it’s because it’s a burning fire.
Mitigation plan The numbers you share are meaningless unless you share a plan on how you intend to fix this problem.
The agenda for the BoD will be led by the CEO. The CEO will also set the tone of the meeting, as such whatever it is you prepare has to be aligned with the overall goals and theme for the meeting. Your narrative and data are all in support of the overall story that your CEO wants to share with her board. Hence, if the overall theme is that of scaling the business, you should be prepared to talk about how you are enabling this outcome, amongst others. Your talk track might include other topics, but you must include ones, at least if applicable to you, that are relevant to the overall company theme. Your CEO and CFO will almost certainly ensure that the content you create is aligned and that the overall BoD material is cohesive.
Lastly, the themes I presented are not mutually exclusive. You might find yourself in a situation where you need to address more than one simultaneously. That’s ok. Another important thing to note. You must share an honest and accurate picture with the BoD. That means sharing what is working well, and critically, what isn’t. You must also show that you understand the challenges you are facing and outline how you intend to tackle them. Do not raise alarm bells without offering how you intend to put the fire out.
I would also caution you to carefully select what you intend to share with the BoD - especially data and metrics. Once you share those, the BoD will expect to see them in future updates. For example, if you share bug trends because you are faced with a quality problem, then you should share that updated data until this problem goes away. Hence only share data that is relevant and is readily available.
"The numbers you share are meaningful unless you share a plan on how you intend to fix this problem. "
Did you meaningless here?