The Story of How We Discovered Middle Metrics and the Real Problem We Solve
Hi, I’m Amanda — founder @ Staat. Back in the day, before I was chasing entrepreneurial dreams, I played highly competitive tennis. That’s right, I was chasing a small yellow ball around a 27ft wide court every day for 8+ hours a day. I was so serious about tennis that my parents homeschooled me so that I could pursue my professional dreams.
Although tennis didn’t work out, and I eventually made my transition into other fulfilling endeavors — there’s one particular experience that stuck with me and continues to drive my passion for building Staat — a visibility and planning tool for engineering managers.
There was a particular year in my career where I was gradually getting better in practice, but it wasn’t translating to competitive matches or tournaments. I was growing increasingly frustrated because I felt blind to the gap that was only growing wider. I felt so unproductive that I wanted to quit and find something else to do. I needed something to augment my physical advantages to get to the next level.
Then came “stats” or metrics, as others like to call them. One of my coaches, aka my dad, decided to not only sit me down to watch film but also to go over match statistics. There were various levels of metrics. He started with granular point by point metrics, where we discussed why I missed a forehand or how I ran the 2–1 play and managed to make my opponent make the mistake. Then there was the higher level metrics, wins and losses. These metrics helped me determine if I was meeting annual goals of moving along the semi-professional circuit.
Fast forward to where I am today. I’ve managed various product/engineering teams over the last 5 years and was met with the same seasons of inefficiencies, frustration, and lack of clarity on how to meet milestones consistently. These milestones weren’t high-level where I was measuring “organizational” efficiency (parallel to win/loss records), and it wasn’t granular enough to get into the minutia of development details (parallel to I won/lost a single point). The milestones I was trying to hit consisted of understanding team momentum, improving predictability, and building more effective relationships between engineering and product and ultimately our customer.
I spent many sleepless hours attempting to define the metrics needed to effectively and productively play a frontline manager position. I took it back to what I knew best, tennis.
I hit the moment in my career where tournament play matched practice play and I started meeting higher level win/loss goals. I thought back to what I could attribute this growth to: the constant review of match statistics.
Not the granular point by point stats, nor the higher level win/loss records. But the stats right in the middle, helped me understand the momentum of the match. A common match-play scenario where the match was tied and I’d make unforced errors out of nervousness that would hand the momentum to my opponent. Although frustrating, once I could pinpoint these bottlenecks, I could go back and work out the kinks both physically and mentally.
{Sidenote: As I was trying to define what these metrics were called — I told my co-founder (David Kyle Choe) this entire story. I described it as not being low but also not being high-level, and then asked, “What’s that called?” He quickly replied, “Middle Metrics.” And this is where “Middle Metrics” was born.}
After identifying these middle metrics, I was confident that no matter what happened in the match I could recognize what strategy needed to be implemented to meet the ultimate goal: winning.
Middle Metrics is the fuel that not only athletes but also engineering managers (and their team) are often missing. This fundamental lack of Middle Metrics causes self-doubt, team-wide frustration, project inefficiencies, and ultimately underperforming organizations and products.
They’re designed to create a fair and objective source of truth for both player and coach or manager and developers. They’re used to help see momentum in ways that you can’t see when left to your own devices. They augment and streamline an already powerful toolkit of project management and developer tools giving you visibility throughout work cycles (Kanban) and sprints (Scrum). They give you the insight needed to make the right decisions quickly and foster more effective communication between the team. Leading to greater predictability and confidence across the business.
I could stop here as these are all value props that will help you achieve greater work. However, one of the biggest engineering manager pitfalls is imposter syndrome and not understanding one’s own productivity exclusive of team productivity.
Let’s go back to tennis, one final time. During the heat of the match, it’s only you out there. You’re left to make split-second decisions based on factors a bit out of your control while simultaneously displaying a level of confidence to everyone (your opponent, your team, the crowd, sponsors, etc). When you’re playing matches and flying blind, it’s excruciating.
It’s a constant guessing game, and guessing alone can have you feeling like you don’t know what you’re doing — translating into self-doubt and inner frustration. Nothing is worse than coming off the court and your coach asking, “what happened out there?” And when you can’t answer confidently and start taking stabs at what you think went wrong in the match — imposter syndrome can set in quickly.
Parallel this guesswork with sprint (or cycle) planning, reporting, making delivery predictions, developers and cross-functional partners expecting you to know what’s going on, and trusting you to know specific answers. All this can become frustrating and ultimately lead to self-doubt when making half-way guesses and pre-formulating answers for when things go wrong. You’d think we’d be able to use existing tools to land at a solid source of truth since it’s our job to connect the dots between product and engineering.
However, this isn’t the case. Our current, traditional toolkits are built for developers and/or higher-level managers. They’re helpful to a degree, but fail to help us move into a more strategic management role. What managers believe to be management and what they’re doing in practice often don’t line up. Middle Metrics are designed to bridge this gap and take the guesswork out of management. Once you’re operating from a place of certainty, vs. a place of uncertainty — your world changes. Your tournament play begins to match your practice play. You feel more confident and ultimately your team feels more confident with you at the head.
Staat is designed with this thought process at the core. To build a visibility and planning tool that serves Middle Metrics helping you make swift, effective decisions that ultimately drive long-term advantages. Like improving predictability and cross-functional relations, driving organizational efficiency, and continuously delivering products our customers want.
Check out Staat today and start building a toolkit made for engineering management. Achieve your dreams and get there with clarity.
