What Engineering Leaders Can Learn from Stripe's BFCM Product Dashboard
As the Black Friday/Cyber Monday season approaches, Stripe has showcased its product dashboard at https://bfcm.stripe.dev/.
While it's a gem for Product Managers who seek inspiration about how to build their org's scorecard, I found it also as an inspiration for engineering leaders who would like to empower their teams to be high-performing product contributors, not just engineers who write code or deliver features.
Disclaimer: This article is just my hypotheses and comments "from the outside" and has not been confirmed with anyone from Stripe.
There is no "Product vs Engineering" at Stripe—There is one Stripe
Stripe likely has numerous detailed data dashboards covering product, business performance, technology, operations, and more—a commonality in organizations ranging from startups to large corporations.
However, during one of their most critical business periods, they produced a concise board focused on aspects most crucial to their product.
The primary KPI, Transaction Volume, stands as a potential master score for the entire organization. It's clear, understandable, not very nuanced, and can be easily tracked month by month or year over year, so everyone in the organization understands how the company is doing.
Businesses Having Their Best Day Ever on Stripe shows that the company is focused on customers, which aligns with its mission: "Stripe's core mission is centered around increasing the internet's economic potential by providing powerful and user-friendly tools for businesses to manage their online transactions.".
While a company's mission is usually quite wordy and blurry, this metric shows the here-and-now tangible representation of this statement.
Fast forward to technicalities.
Transaction Volume derives from Total Transactions within a specified timeframe (from Black Friday to Cyber Monday), leading to critical engineering metrics:
Transactions per minute
Load vs. Capacity of system
Simple as that.
As an exercise, think of it as if you were setting goals for your engineering team.
We can use countless objectives - from DORA metrics to test coverage, the number of instances in the context of load, the number of server errors, and more. Many of these can be important in your local context (if you can serve only a few concurrent users and CPU usage spikes to 99% all the time, it's clear something is wrong).
The key is distinguishing between supporting metrics and the ultimate objectives they serve.
In the context of Stripe's BFCM:
To achieve a transaction volume of nearly 20 billion USD, approximately 300 million total transactions are needed (assuming known transaction avg. volume)
This breaks down into transactions per minute (average/peak).
This, in turn, translates to the number of requests their API must handle.
Add to that availability SLA: 99.999% API uptime.
These insights are invaluable for engineering leaders. Based on this information, you can think of system quality attributes like scalability, availability, reliability, performance, and resilience, which are meaningful for business performance.
No more random tech goals set by engineers to overoptimize their systems.
The second board from Stripe's BFCM 2023 Recap breaks down the platform into key products. Let's do another exercise to find possible technical goals from these core KPIs.
Consider Time Saved With Link. It likely represents a value proposition where the automatic filling of payment information boosts conversion rates, contributing to Transaction Volume, the master KPI.
Potential technical goals for the engineering team might include:
Enhancing the user experience for data entry (layout responsiveness, loading time, validation errors, etc.).
Monitoring conversion drop-offs (e.g., failed SMS deliveries).
Exploring integrations with various platforms (e.g., can we use any Android/Chrome/iOS/etc. API to autofill some information even faster?).
Optimizing the SDLC process. In a feature like this, a user experience needs a bunch of iterations. It can be critical for success to iterate over it daily rather than during a once-a-week release cycle.
These are just a few examples based on my limited knowledge of Stripe's internal challenges.
I highly recommend doing similar exercises to align your team's work with your company's KPIs and objectives.
The key takeaway for engineering leaders is to focus on more than just input metrics like commits, story points, or closed tickets. These don't necessarily reflect your contribution to the company's success.
You might build goals around throughput—deployments, no. of microservices, bug fixes, or performance improvements. You can create incentives around delivering features on time and celebrate public launches of the product. And these all can be valid, especially when contextualized within broader product goals.
However, to maximize team performance - align the team's activities, goals, and progression with the organization's scorecard. This isn't always straightforward, but connecting your engineering efforts with high-level product goals can significantly enhance your impact on the company's success, create alignment, and deepen the understanding of your work's true value.
Let's Stay in Touch
If you're interested in brainstorming ideas on aligning your engineering team with your business/product goals, feel free to reach out to me at firstname.lastname@example.org. I'm eager to share my experience in implementing these practices in engineering organizations.