May 29, 2024
What does a Chief Technology Officer do?
When I talk to groups of engineering leaders, I’m sometimes surprised by the response I get to this question. No two answers will be the same, and the definition often boils down to a variation of taking orders from other areas of the business. Instead of having a seat at the table, CTOs and other engineering leaders are focused more on how to manage requests from their executive peers.
The reality is that engineering leaders should be strategic partners with their executive peers. Instead of taking requests from sales, marketing and product leaders in one-way conversations, CTOs and VPs of engineering should work cross functionally to help their business partners understand what’s feasible and make the conversation a two-way street. By choosing the right metrics to communicate with business leaders, CTOs can gain influence and improve outcomes for the business as a whole.
Engineering metrics are complicated, and there aren’t one-size-fits-all solutions. We’ve recently covered the challenges engineering leaders face when measuring productivity, as well as the nuances of using metrics to communicate with an organization’s board of directors or investors. But what about your business partners? How do you use metrics to communicate with other members of the C-suite or management team?
What do business executives need to know about engineering?
While engineering leaders can typically communicate to their board of directors with a common set of metrics, each of their executive peers will have different interest areas and priorities. When communicating with your executive peers, the most effective strategy is to remove the metrics that are engineering-centric and instead tie engineering work to their vernacular. Instead of providing metrics, provide a common language to communicate about the work being done.
Your finance team’s interests will align most closely with the board. How are resources divided among different products, and how is investment broken down between the product roadmap, keeping the lights on (KTLO), and general support? Finance leaders will want to dig a bit deeper than the board — how are you measuring unit economics, and how do you calculate the cost efficiency of the team? You can help your CFO understand cost centers by explaining which resources are being used on which aspects of product development: for example, you can show how your higher-paid Silicon Valley engineers are focusing on the innovation expected to yield the highest returns and differentiation, while lower-cost employee centers are taking on less differentiated work in addition to driving new features. Finance teams also want to understand your infrastructure — how much are you spending on cloud costs and software licensing, and how will this scale with new customer acquisition?
Sales and marketing leaders have different priorities entirely — they primarily want to know when the deliverables will be ready. Your CRO and CMO don’t care about the challenges your team is facing, and they aren’t interested in jargon-y engineering metrics like story points. Use metrics to show your sales and marketing colleagues what you’re working on and when it’s going to be released — macro-level target release dates — while building trust by providing updates against that information and explaining what you’re doing to lower risk levels. Sales and marketing leaders may want to double click down from product themes to feature-level detail, and customer success managers may ask to see how launches are tied to customer requests. By being proactive and prescriptive with these business partners, you help to make their lives easier.
Above any other business unit, engineering leaders should be tied at the hip with product leaders. There’s a reason why R&D as a whole encompasses engineering and product, and it’s critical that a CTO and CPO are communicating frequently at a peer-to-peer level. When communicating with product leaders, avoid the temptation to get into the fine details of mechanics; instead, focus on aligning on capacity and anticipated effort. When these two teams are aligned on how much time is being spent on planned work and how much is being spent on unplanned work, it helps both teams to hit commitments and avoid oversubscribing their resources. Communicating the anticipated effort involved with each new feature also helps product determine the ROI on each project, allowing to make more effective bets on the product roadmap.
Engineering leaders can also work effectively with product leaders by talking about the importance of focus and avoiding context switching — how many features are shifted during development, and how many do the engineers have to lay down or pivot away from? This is a matter of holding the product team accountable: when they change their mind about features, that can cause the engineering team to have to throw away work and become frustrated. Engineers want to know that their work matters: context switching and wasted work can negatively impact developer satisfaction, a top-of-mind concern for engineering organizations as they work to retain employees and avoid the high costs of recruitment.
What metrics matter to executive peers?
Engineering leaders have an opportunity to reframe their conversations with business partners by choosing the right metrics. Instead of talking about how to improve performance or get more value out of their teams, engineering leaders should concentrate instead on capacity, distribution of resources, and on-time delivery.
Here are three specific ways to position engineering metrics when communicating cross functionally:
- On-time delivery: Across all functions, this is the metric that demonstrates other business leaders can trust their CTO or VP of engineering. On-time delivery is a tough metric to deliver, but consistent reliability demonstrates that the engineering team is tracking their performance and responding quickly when things start to go off the rails. Engineering will always be unpredictable to some extent; providing proactive updates and showing that your timelines can be trusted is the most valuable way engineering leaders can use metrics with their executive colleagues.
- Engineering capacity: Keep it simple. How many projects can your team handle at a time, and how many of those projects are devoted to work that isn’t cross-functional? If your team can take on 10 projects at a time and three of those are devoted to KTLO, then the rest of the organization understands that engineering has capacity for seven features. This then allows other business leaders to make decisions on what they want to prioritize: knowing that the engineering team is limited to seven projects, which are the most important to the business overall? This mindset keeps everyone focused on realistic timelines and deliverables instead of looking for ways to squeeze out more efficiency. Resist the temptation to get too specific or precise in terms of tradeoffs — define projects at a high level and avoid getting bogged down in small details.
- Engineer ramp time: This is another useful metric for setting expectations with business partners. Scaling up productivity is never as simple as just hiring new people. Just as CROs talk about ramp time for new sales reps, engineering leaders can talk about ramp time for engineers — how long will it take until a new engineer is ready to contribute? Ramp time is also an effective proxy for engineering efficiency in general. If it’s taking nine months to ramp an engineer, it could be worth evaluating if there are opportunities to improve your general development process and shorten the overall ramp time.
Updates, risks, costs, timelines
While you may only be updating your board of directors once per quarter, you should be checking in with your business partners on at least a monthly basis. Again, the key to gaining influence and increasing effectiveness is to speak in the language your peers understand. You can communicate about project progress by talking about the percentage complete and target delivery date — anyone can make sense of those numbers regardless of their business unit.
Provide your partners with a high-level overview of the lifetime costs of each project. This will also give them the context they need to map engineering work against business goals and potentially adjust their priorities accordingly.
When you check in with other business leaders, brief them specifically on any relevant product updates and on the risks you might currently be facing. Don’t be afraid of transparency: speaking honestly about risks and challenges allows your executive colleagues to better prepare their own operations and avoid being caught flat-footed if things don’t go according to plan. Building trust means building influence.
To learn more about how Jellyfish makes it easier to measure and communicate about engineering effectiveness, visit our product page for business alignment.
