Hello and welcome to Making Data Matter. Today we don't have a guest interview for you. With summer schedules and travel from both myself and Troy, no guest interview yet. More upcoming later this summer, but this week we have something a bit different. I did a presentation a couple of weeks ago on LinkedIn around measuring success for data teams. And so what you're hearing now is a recording
of that presentation. If you're interested in seeing the presentation with the slide deck and visual elements, you can see that by the link in the
show notes below. This is the audio recording of it and allows you to walk through just the framework that I've been talking about with people on LinkedIn and in my daily emails for a while around how do you measure success, what are the problems and challenges data teams face, what's a practical framework for thinking through how to do that better, and what are the results of when you do measure success well as a data team. So please enjoy this presentation
on measuring success for data teams. So here we are, you're at the measuring success for data teams webinar or alternatively titled how to get leadership to pay attention to you. And so we're gonna get started here. My name is Sawyer Nyquist. I run the data shop solo consulting practice. I'm based in the beautiful woods of West Michigan. I'm firmly convinced that Michigan has a state with the best summers and we are in the peak middle of summer right now
and I'm just savoring every minute of it. So I'm doing this live stream right before this. I was out mountain biking and right after this I'm probably gonna head back outside and enjoy some more beautiful afternoon in Michigan. So beautiful summer day here. I hope it's beautiful where you're at as well. But let's get rolling. So what is this conversation all about? And I'm gonna give us a little overview of where we're headed. So measuring success for
data teams or how to get leadership to pay attention to you. I think these two ideas are closely related and we'll hopefully unpack that why as we get going. But I want to start here. Here's where we're headed for today. We're talking about the problem. The problem around measuring success in your data team, both what happens if you don't and why is it so hard to measure success. Talking about the
problem. We're gonna talk about a simple framework, my framework for how you can work through success measurements and movement and progress towards success. Some basic, there's some simple tools for that. A simple framework. We're gonna offer you some practical advice about how to go about measuring success and working on these measurements that we're gonna talk about and implementing the framework that I'm gonna present. And then we're gonna talk about the results.
What happens when you do this well? What happens when you know how to measure success and you implement it well? What happens to your team and to your career and to your organization? That's where we're headed for today. So problem, framework, some advice and then some results about what that's gonna look like. So let's dive in here first with the problem. What if you don't measure success? What if you just skip this part and say I don't have a measurement of
success for my team, I don't need a measurement of success. What happens? Well a few things come to mind and there's probably dozens more that we could talk about but here are a few that come to mind right off the bat. I think your team morale suffers and I've seen this. Your energy and the enthusiasm of your team is, your team ends up with the enthusiasm and the energy of painters tape. There's no excitement, there's no clarity
about where you're headed and so your team morale suffers. That inevitably leads to turnover on your team and inevitably also leads to difficulty hiring. I think your team morale suffers if you don't have a clear measurement of what success is. Number two, confidence wanes and in this I specifically mean the leaders confidence weight. So you as a leader of a team, your confidence, you start to lose confidence that you know what you are doing and why you're doing
it. It becomes you get lost in kind of this busy work of tickets and reports and meetings and stakeholders and requirements gathering you like what are we actually doing? You start to lose confidence that you know what you're
doing and you know why you're doing it. A closely connected to that I think is also you can't prioritize is you get overwhelmed with the number of requests that come in, the number of bugs that are present in the system, the number of opportunities for new things to do and you don't know how to prioritize all the different opportunities and all the different problems that are hitting you. You can't prioritize so when you don't measure success I don't think you can
prioritize well and most importantly perhaps leadership ignores you. They don't know what you do. Your technical activities are meaningless to leaders who are one level and two levels above you. They really don't care how many pipelines you built, how many lines of code you wrote, how many visualizations
you crafted. That all falls on deaf ears and so if they don't know what you're doing they start ignoring you and you struggle to get their attention and ultimately that either ends in frustration from you or elimination of your positions and your team. So great data teams know what success is, how to measure it and how to communicate it and that's what we're focused on here. Great data teams know what success is, how to measure it and how to communicate it and
I think that speaks to all the different problems we face so far. So why is it so hard? So we talked about the problem of why this exists. Why is it so hard to measure success? Too many different answers here, so many different answers. So let's let's start here a little bit and explore what types of things people come up with. When I ask data leaders how they measure success I get things like this operational efficiency. They start to measure success by operational
efficiency. Maybe that's data quality or no turnover on our team or the pipeline run times or down or we turn around tickets really fast. Maybe we do things like internal team culture and employee morale is really up and my team culture is great and maybe that's a success measure or maybe people measure success by technical goals like we completed our data warehouse, we decreased our cloud cost. Maybe it's about stakeholder perception of the data team. Maybe you
start to measure your success based on the NPS score of your stakeholders. Maybe you you know somehow are judging how much the stakeholders like you and that's your success. I think we see data teams. I see and talk to data teams. I hear from data leaders constantly a variety of different things. Maybe no one's on the team is working overtime. That's a success. Maybe completing data quality checks at a higher percentage is that's success. These answers range so widely. So
why is it such a hard question to answer? Does anybody confuse because it's a really hard question to answer. It seems like in our industry and in our space it's a hard question. I think everybody's a little bit confused about what we're doing here and with the splattering of answers that we get. So here are a few things that come to mind about why this is difficult. So first off I think data teams struggle with this because we don't have a clear vision for
data in our organization. We don't have a clear vision for data in our organization. So is the data team a group of ticket takers that turn our reports? In what way or by what methodology are data people actually supposed to support decision-making? Can you tie any actual business results to something the data team delivered? There's no clear vision for what data does in an organization. So that's why our success metrics are the things that we're measuring
success on range so widely because there's no clear vision of what it is. I think that's maybe one reason why this is so hard. A second reason why it's hard is because data teams align to many different functions in an organization. So data teams can be embedded in the business unit. They can be centralized. They could roll up to finance or marketing or IT or software
engineering. And because of the numerous places that data teams sit in the organization and on the org chart, I see data leaders constantly shifting views about what success looks like based on who they report to. If it's finance, that dictates some of it. If it's engineering, that dictates some of it. If it's embedded or if it's centralized, those all dictate how we measure success on our team. And I think that leads to some of the confusion and the difficulty
with this question. Another thing is, a third reason that I'll throw out of why this is so hard for us to do is that we haven't been asked to define success before. At least not in recent memory. So for the last decade of low interest rates and cheap cloud costs, data teams could build all sorts of fancy tools and exciting data projects. And the actual ROI of those projects was never really demanded because R&D budgets were flush. It was cash was cheap
and it was easy. Well, that has changed. If you've been paying attention the last couple of years, the cheap money is gone and now the budgets and the staffing cuts are here and we're scrambling to define success in new ways or actually needing to define success for the first time. So I think that's another reason we struggle with this question because it's the first time in recent memory in a decade or so that we've had to answer this question well. Additionally, I
think we love data too much. This one might sound a little bit counterintuitive, but I think we struggle with the question of measuring success because we love data too much. It's hard for us to find clarity about success when we have or we know where to find any data point we want. And our dashboards are crowded and clouded with KPIs that make any sort of uniform message really
unclear. When you've got a dozen different data points you're looking at constantly, these six markers are going up and these six indicators are going down and these six over here are going sideways. Well, good luck sharing that progress clearly to your team or good luck sharing any sort of progress from those flattering of charts to leadership above you. I think we love data too much or we get overwhelmed with data because we love data points and we love charts.
And finally, I think maybe one more reason why this is so hard for us is we have ambiguous definitions of measurement. So leaders will tell me they measure customer satisfaction or data quality or by contributing to business goals, but then they never clearly define what those terms mean and how they quantitatively measure or use them to track success. And so for as much as you love data, most of success measurements on data teams end up being we just trust
our gut about our success. We just say, you know what, it feels good. We're moving the right direction. I can tell kind of how things are. Culture feels good. Teams excited. Energy. We're getting good vibes from the people around us. The business is maybe doing well overall. And so we just end up trusting our gut, which really kind of sounds like, trust me bro. Just trust me bro. Like we're good. And so for people who love data, this is our default standard, which is
kind of surprising. Okay. So what if we made this easier? So it's a hard problem to solve. And I don't think it's a problem that we've solved very well in many cases. What have we made this easier? And I want to introduce here a simple framework for measuring success. Data teams are terrible at this. We come up with a splatter of metrics, throw them on a board and call it success. And so
maybe we do KPIs or OKRs or smart goals or metric trees. But here's a simpler framework that I think allows us to speak to all the different parts that could go into success metrics. And so I call this the one, two, three, four road trip method. I recently went on a summer road trip with my family on vacation. We drove from Michigan down to Florida. It's a long ways, about 20 hours of driving. And so I've thought about road trips a lot recently. But let me
introduce this to you. There's one, two, three, four. So one, you get one destination metric. Define one destination metric. This is your terminal goal for your team. This is the purpose your team exists for. It's not progress towards something else. It is the end purpose. So you define one destination metric, just like you would on a road trip. And then two, you get two away point metrics. So way points are those key indicators or key markers on
the journey that track progress. They are crucial for tracking your progress towards your destination goal. So you define two way point metrics. And then you get three turn signals, three turn signals. Turn signals are also called decision metrics. They are specifically defined to alert you when you hit a decision point. And we'll talk a little bit more about how to define those a little bit later. But you get three turn signals. And then the last one, four
gauges. So a gauge is an indicator of what's happening operationally on your journey. So what's your speed? How much gas is left in the tank? What's the temperature of the engine? These are important to have identified, important to maybe have available, but they're pretty pointless to stare at constantly. So gauge, there you go. One, two, three, four, one destination, two waypoints, three turn signals, four gauges. These are all the metrics you get. You get up
to one, up to two, up to three, up to four. You can have less if you want, but you can't have more. These are the rules. I made them and I enforce them. So at first, this feels fairly easy. But where I see teams struggling specifically is with that destination metric. And so consequentially, the rest of the metrics can't fall down flat or don't come together until this first one comes together. So let's talk about destination metric. Destination metrics are the
ultimate goal of your team. So let's talk about how to define a destination. I think you have three main options when you're picking a destination metric. And so before I explain these options, I need to introduce you to the box. All right. I need to understand the concept of the box. Okay. So humans are great at thinking in boxes. It's kind of a necessary coping mechanism for surviving
in a really complex world is we put things in boxes. We're wired to draw a box around and to optimize our decision making for things that are inside our box. So we make choices based on what's best for us in our box, both biologically and psychologically. Like it's nearly impossible for us to not draw these boxes. Okay. So for example, in your personal life, your primary box might be yourself and then your family and then your neighborhood, your city, state,
country, planet. All right. That's like the biggest boxes, the planet, maybe the universe, I suppose, but call it your planet. That's the biggest box possible. Those are kind of how boxes work. And so you make choices based on what's in the best interest of the smallest box first, and then you work your way out. So as you move out, it gets increasingly harder to make optimal choices that take into account the smallest box, yourself and your family, and the larger boxes, maybe
your country or your planet. And so you end up with a little bit of attention sometimes between optimizing for the smaller boxes and the closer, more pertinent boxes to you and the larger boxes. And so if you are buying groceries, it's really hard and we can't simultaneously make optimal decisions for my family's health, my financial constraints, while also thinking about the economics and the environmental and the political factors of my state,
country and planet all at the same time. It overloads the human psychology, overloads our decision making engine. And so we end up making some optimizations in smaller boxes. Okay. So we allow ourselves to be rational only in the smallest box, or potentially a slightly larger box. And so this is you end up making decisions around like, hey, well, I need to make a decision about my
family, my health and my financial constraints. And maybe, depending on if you can optimize well on that, maybe you can take a step further, maybe start to think about some other other slightly larger boxes. Okay. And obviously enough, this probably shows up in our workplaces. Our boxes are ourself, then our team, and our department, and then our company. And so just like in our personal lives, we struggle to make optimal decisions for all areas of our life and all the world.
Just like just like in our personal lives, and our corporate lives, we struggle to make optimal decisions for all of our company. And so we focus on optimizing smaller boxes. Okay, so this is similar to a concept in systems thinking called bounded rationality, where essentially we draw boundaries around what we are rational in, and we make decisions based on smaller boxes of
rationality. So you as a team, you as a data team are a box, a contained unit of people with purposes, strategies, flaws, personalities, cultures, goals, and there are clear walls about what's in your box and what's not in your box. And so at the same time, your box exists also in the context of some larger boxes, and then maybe there's some gray lines between some of those, but generally, you know
where your team ends, and where the other team begins. Okay, so fundamentally, our brains create these boxes with boundaries, so we can make sense of our world. And this is important when it comes to setting a destination metric, because boxes are all about what you're optimizing for success is all about what you're optimizing for, and all about what you're striving for the purpose. Alright, so I think you have three choices when it comes to picking a
destination. And so let's talk about those you can pick inside the box. All right. And the box is your data team. So you can pick inside the box, you can pick on the edge of the box, or you can pick option three is outside the box. Alright, and let's let's break these down just a bit more here. So inside the box, there's three types of data teams. Inside the box, your destination metric
is defined by the actions and the results inside the box. Inside the box metrics look like data teams that are things that the data team explicitly controls. So maybe that's decreasing the data cloud cost by x percent, maybe it's maintaining uptime of a data system by y percent. Maybe it's delivering data requests in x number of days, all new data requests. So things inside the box that you control, those are desiccated. That's what a destination
metric looks like inside the box. In this scenario, that's what you're optimizing for. What's in the box, what you control. Edge of the box, your destination metric looks like connected to some element outside your box. So you don't control all metrics, all aspects of the metric, but it's also highly connected and related to work. So an example of this would be of an edge of the box
destination metric might look like stakeholder satisfaction. Okay, so some sort of NPS score or some other method to assess a measure how happy our stakeholders are. That's an edge of the box metric where you control maybe like part of the equation, but not all the equation. The other parts are kind of like out of your control. And so in this scenario, you're optimizing for edge of
the box interactions. The third scenario, and this is the scary one, is the outside of the box where your destination metric is not set based on what's inside the box. Now what's on the edge of the box that you have some control over? It's beyond your box entirely. And so very often when you set an outside the box destination metric for your data team, it's like the
terminal metric of the whole organization or the whole company. That's net revenue, it's student outcomes, it's program participation, it's community impact, etc. It's usually like a terminal goal for the whole organization. And so in this scenario, you as the data team are optimizing your activities to impact something that's completely outside of the box. And so it's a scarier one, it's a harder one. And the natural question starts to come up is, well,
which one should I pick? Which sort of destination metric should my data team have? Because this is how you're defining success and defining what you want to optimize for on your team. And so people struggle here to pick and they can't determine whether they should be inside, on the edge, or outside. But I think asking the should question might be the wrong question. I think better to
start with what is already true about your data team. So let me tell you about the different data teams, the three different types of data teams that fall into these categories. And maybe one of these describes you better than the others. First, let's talk about the inside the box data team. Inside the box data team. This data team are what I call enablers. And their mantra is, here's your data, go be successful. This data team creates reports, ensures the data
is accurate and available whenever needed. And they throw the data over the fence to the business team. And this team uses it. And their focus is on responding to tickets, optimizing data infrastructure and providing data quality. This is kind of the realm of DBAs and data engineers, people who ensure data quality and data availability. That's their world. And if that's your data team's definition of success, here's your data, go be
successful, chuck it over the fence, call it good. That describes an enabler team. And these enable enabler teams are the type of teams that have success metrics and destination metrics that are inside the box. All right. Next is edge of the box teams. Edge of the box teams are what I call advisors. Advisors, this data team accomplishes the same tasks, all the same tasks as enablers, but they have a focus on engaging with stakeholders and providing context around the data and
offering analytical insight. So this team includes things like data analysts or BI developers or data scientists. And their mantra is, let me help you be successful, right? Because they're optimizing for kind of this edge of the box relationships between stakeholders and data teams. And so their engagement with stakeholders is different. Let me help you be successful. There's a sort of
advisor alongside you relationship. Those are advisors. And that's the second type of data team that often has destination metrics that are on the edge of the box. The third data team, third and final data team is what I call the partners. And partners have a different sort of mantra for success. Their mantra is we win or lose together. I don't win if you don't win and we win or lose
together. And so this data team provides accurate data, offers context advice and strategic perspective around the data, but they also uniquely attach themselves to business objectives outside their data team. They are partners with the business and they are at the decision-making table. They measure their success by the organization as a whole. As we talked about, they are outside the
box sort of metrics and destination metrics. Okay. So I think before you can pick a destination metric for your team, you really have to define, decide which type of data team you are. And so you can look like one of these three. Which data team are you? Are you an enabler data team? You already are one of these, so don't try to guess or don't try to make something up or get aspirational. You already are one of these. So first identify what you already are. Do you
operate more as an enabler, as advisors or as partners? And that'll already help you answer this question of the destination metric. So, you know, I've given examples of these already, but enablers, their example destination metric might be data quality. Advisors might be stakeholder satisfaction. Partners might be like an overall business objective, net revenue, student outcomes, etc. It is possible to move from enabler to advisor or from advisor to partner. But that's,
and that might be your aspiration. And we could talk about that another time, but that's probably another webinar that we can get into at a different time. So for now, I think it's best to kind of identify what you are when you're setting your destination metric. What is our team already like? It's going to be too hard to pick a destination metric that doesn't actually align with what your team is like. All right. So there's our boxes and there's how we think about
destination metrics. And having a destination is crucial, and there's no way to be successful without a destination metric. But a destination by itself is a fluffy unicorn. It's mythical, imaginary, and kind of disconnected from reality. All right. So what we need to enable our destination metric are some other things. We need our other metrics. And so let's talk about those other metrics. The one, two, three, four, we cover the one, which is the destination.
Now we've got the two, three, four. We've got the waypoints, the turn signals, and the gauges. So let's talk about principles for these. First is the waypoint metrics. These metrics are reliable indicators of progress towards your destination metric. These are the signs along the road that show you how many miles you are from your destination and be able to track progress towards your destination. So the key question you might be thinking about here is what
things need to be true for our destination metric to be a reality. What things need to be true for our destination metric to be a reality. And then you choose, you're likely to go with numerous things that need to be true, but you narrow your focus down to identify the two most influential things. It's going to be subjective. That's okay. You might have to swap out your waypoint
metric later on down the road. And that's fine too. I think the two things that right now seem to indicate and are the most influential towards your destination metric, those are your waypoint metrics. These tend to be a little faster feedback loop for you. Waypoint metrics will provide faster feedback than a destination metric will, which is great. So you can know that you're making progress even if the destination metric hasn't moved yet. Next, you've got turn
signals and then we've got three of these. So a turn signal is tied to a specific decision. These metrics are designed as a decision statement. This isn't just a box with a big number on it. This says when X goes above or below Y, we'll make this specific decision. We'll make this specific decision. So what this looks like when you're trying to figure out what are our decision metrics is we think about what is the dilemma we face trying to make progress toward
their destination? What is the dilemma that we face? What are these decisions that we're making that are going to influence our decision? As you start to identify what your destination is and what your waypoints are, now you can figure out what are the things that I'm doing week in, week out? What are the decisions that I'm making, maybe it's every month, that are really important and I need to optimize around those decisions that are going to actually
move these other things. And you design a metric around decision making. There's all sorts of details we could dive into about how to design decision metrics and how to reduce the uncertainty and decisions that you're making using data. Again, that's a webinar for another time. But that's turn signals. The third one you've got is gauges. So gauges give you overall
operational perspective, but they're not actively monitored. So you can just imagine staring at your speedometer for the length of a 10-hour road trip or 20-hour road trip all the way to Florida. It's pointless. You're staring at your or staring at your gas gauge and watching it just like slowly ticked out or maybe your electric charge slowly ticked down. These are not things you stare at. Gauges are not something you review every day. There are things that need to
be available should something go wrong. If my car all of a sudden runs out of gas and I had no way of verifying that, that would be a problem. Or if I had no way of knowing how fast I was going when I was driving, that would be a problem. But it's not something I'm going to stare at the whole time. So they're reviewed on an infrequent schedule, maybe once a month or something or less, but they are not
actively managed. You're not managing or optimizing towards your gauges. You're managing and optimizing towards your waypoints and towards your destination metric. And I could give some examples of these, but I think in the interest of time, we're not going to walk through it right now. So I want to give a little bit of a behold, like, wow, this could be great and beware. Watch out. Because once you start to define metrics and measurements for success, there's something
to behold and there's something to beware of. Because designing success metrics for your team can unlock a new level of energy, clarity, and confidence for people on your team. It just does. Once they can see a destination and a goal and progress and they have visibility into what's happening and they can get on board with that vision and that purpose, you can unlock a new energy. But at the same time, you have to beware because metrics are the primary
way your team members and organization is incentivized. Especially when these are our destination metrics and purpose metrics and success metrics. Success metrics are naturally and inherently something that your team wants to optimize for. And so without proper care and without your eyes being wide open, your metrics could introduce toxic dynamics and toxic incentives for your
team. So incentives are all about what people optimize for. So a salesperson who's on a commission plan optimizes for closing the most deals to increase the commission. Regardless of anything else, they need to close deals. Regardless of their good deals, they need to close deals. Regardless of their great customers, they need to close deals. Regardless of if it's a good fit for the product, they need to close deals. Because that's what they're
incentivized for and that's what they optimize for. Same thing with customers for people that are measured on how many support cases they close. And they're going to optimize for speedy resolution. Regardless of what might be ideal or optimal, on the big picture, their box gets very small and they start to optimize for speedy resolutions because that's their success metric. And
so it's how do we turn tickets as fast as possible. Or a software engineer who's measured by some sort of toxic incentive, like how many commits they'd make or how many store points they deliver. And so they can optimize that in all sorts of poorly incentivized ways, suboptimal ways at the larger picture. But if you set the success metrics wrong, they're going to optimize it the wrong way. And at least it's toxic stuff. So these success metrics will be gamed. Promises
for sure. These will be gamed. That's what people do when they want to, when they're incentivized to optimize something. You can't change that. So what can you control is make sure that your success metric is something you want people to game. All right. Don't hate the game. People are going to game your metrics. Play it. Play the game. Set up your success metrics and your incentives and what you're trying to get your team to optimize for. Set that up
to be something that you want it to be. You want them to game the system to optimize and to think rationally and most optimal about what your metric is. And so make sure you set it well so that people don't introduce toxic incentives to play a game you don't want them to play. Set up the game that you want them to play. And then everybody gets excited and energized by the progress. Okay. Behold and beware your metrics. Next, we'll talk about
designing your metrics. Once you've kind of defined those four things, one, two, three, four, your destinations, your waypoints, your turn signals, and your gauges, you have to think about designing them in detail. What data do you need? What information do you already have? And what information do you need to collect? You may not have all the information you need and you might need to figure out how do we actually collect the right details and the right
information to track this metric. That's okay. You probably aren't going to have everything you need in front of us or very likely you're going to be collecting data and presenting data in a different way. Probably your turn signals specifically show up differently than you have in the past. Most people don't have turn signals. And your destination metric might look different. Your waypoints might look a little different. So how you're tracking and
collecting that information kind of change. That's part of designing the metric is what are the data points required here? And it's usually not just one data point. It's usually a handful of data points that get aggregated or pieced together or optimized in a specific way to give you the holistic view that you want for each of these pieces. So part one is kind of like what data do you need? The second piece of this is how will you monitor these
metrics? And there's a lot more details we could go into on all this. But how are you going to monitor? Is there alerting set up for your decision making, for your turn signals, for your decision metrics? Are they going to be reviewed weekly, monthly, quarterly? Where will they be visible? Who will review them? Whose metrics are these responsible for? Are there any external incentives also applied to these metrics in terms of promotions or
bonuses or a team party or outing, et cetera? How will they be monitored and when are they reviewed and when are they communicated? We'll get to communicating more later. So that's about designing your metrics is making sure that you have some tools and you're thoughtful and strategic about keeping track of them. You go through this work of setting them all up and make sure you actually monitor them. And third, you're going to iterate. So
schedule metric reviews. The metrics that you design at first, you're going to give out your best bet. You're going to do your best to think through this strategically and well, but they're not going to be perfect. And so scheduling reviews, maybe this is monthly, maybe this is quarterly. If you get feedback quickly on these, there's quick feedback loops. You might need to do this a little quicker or you might be able to review them faster. And your
first metric won't be your final one. And your metrics will shift, which is what we're going to talk about in just a second. Because here's how this lays out. So your destination metric never changes. Best case scenario, your destination metric never changes. The only time it might change is if you are strategically moving your data team from perhaps an enabler and inside the box destination metric to a advisor and to an edge of the box destination
metric. In that case, your destination metric might change. But unless you're making a strategic move like that, your destination metric never changes. It's very sticky. That's the destination. That's the purpose of our team and why we exist. The waypoint metric rarely changes. Occasionally, you will start to uncover through time and iteration and practice that certain things actually do influence, maybe other things influence the destination metric a bit more than
your identified waypoints. And that's fine. Rarely these will change. But occasionally they will as you learn and get better. Turn signals will probably change more often. Those will often change as you evaluate, as you look ahead to the next quarter and realize what are the key decisions that are relevant and what are the key dilemmas we're facing in the next quarter and how do we optimize
around those. And so maybe next quarter it's hiring decisions. Hey, we've got some really strategic hiring decisions to make and we need some turn signals around hiring and staffing and team structure. Maybe it's around cloud costs and you have some turn signals around cloud costs that are, again, connected to your waypoints. Or maybe it's around stakeholder engagement and et cetera. So those will often change. And by often I mean quarterly at most. These should
not be changing weekly. They're quarterly metrics. And you actually might have, maybe you have 10 total turn signal metrics over time and they kind of like rotate through. You have three or four or you have three that show up every quarter and they kind of like slide in and out based on what the emphasis and the dilemma is that you face at different points in the year. Those will often change. And I think your gauge metrics will often change. Well, what you track
operationally will probably change. Certain things will fall out of importance. Other things will slide into higher levels of importance. So your gauge metrics will change. But destinations never change. Waypoints rarely change. The lower ones often change. And so your quarterly reviews or your sprint reviews or your monthly reviews of your metrics are usually evaluated in the lower ones. Are these gauges, turn signals, and waypoints, are those actually still serving us well?
Are there some adjustments and tweaks or some wholesale changes we need to make in those? All right. So here's the last part that I promised you. How to get leadership to pay attention to you. And so I want to share four ridiculously easy steps to sharing your progress and success with leadership.
If you went through the work of walking through this one, two, three, four road trip method and thinking through how your team is designed to fit in relation to the box and the rest of the organization and what you're optimizing for and the incentives in your team, you will be well served to take some time to think about how that's going to accelerate the growth of your team and the attention that leadership gives you.
Don't skip this part. The clarity and progress as a team, your clarity and your progress as a team is really short-sighted. If your leadership is not aware of how your team is successful, they're not aware and involved and attentive to how your team is successful. And communicating your success to leadership, that's the fastest way to not just get attention and recognition, but budget, project approval, promotions, career satisfactions. Listen, I'm a data guy. I spent my career
in data. I am for you, data leaders. I am a fan of making you guys as successful as possible. I want to see data managers, directors, VPs grow and find ridiculous success in their career, at peak success in their careers and with their data teams. I want to see leaders getting on board with the data agenda and with the opportunities and the value of data. And so I'm on your team here. And that's why I care about how do you get leaders to pay attention to you. This
is what matters. So here's four ridiculously easy steps to showing your progress. Number one, tell them how you are measuring success. Tell your leaders how you're measuring success. Once you've walked through this process, you will have clearly defined ways of measuring success. Tell them. Tell them how. Tell them about what you've defined. Second, tell them why you are measuring success this way. So knowing how naturally that's going to start to come up.
Why are you measuring success this way? Talk to them about your thought process for why you defined the metrics the way you did. Your rationale, your decision points for picking the metrics that you did, how they how they fell into this one, two, three, four grid. That gives them not just knowing what's going on, understanding your thoughtfulness and strategy behind why you're measuring what you are. Number three, tell them when you will share progress with them.
Your leaders probably won't be regularly checking in on your progress. Many leaders, especially as you go, if you think about leaders one, two, and three levels above you, they don't have time to regularly check in on your progress. So it is your job to communicate when you will share progress with them. Hey, I am going to share with you every month at our monthly one-on-one. I'm going to share with you at our quarterly reviews. I'm going to share with you weekly at our one-on-ones, etc. Figure
out what the cadence is. Tell them when you will tell them. And then the last step, tell them the progress when you said you would. Don't waste your efforts on this process by then ignoring and failing to actually deliver on what you promised. One of the biggest problems that people run into is setting expectations and delivering on the expectations. And so here's this point here. If you don't tell someone what to expect,
how will they know when they've won? And so a big part of that is telling them what to expect, coming through on that so that they know that they've won. If you don't tell someone what to expect, how will they know when they've won? You are being very deliberate and pedantic about how you are describing and explaining your team success, regularly sharing that with them, offering them, making it ridiculously easy for them to understand your success.
And it makes it so much easier for them to then share your success, give you the recognition you deserve, and continue to invest a time and attention into what the data team is doing because they can see how it's moving the destination goal. They can see how it's connected to business outcomes. They can see how data is actually helping the organization as a whole. So tell them how you're measuring success. Tell them why you're measuring success.
Tell them when you will share progress and then do it. Then tell them the progress when you said you would. So measuring success launch pad. So if you're looking for clarity for how to measure success for your data team, confidence about your progress towards your goals, renewed focus for prioritizing your work on your data team, tangible tools for sharing success with leaders so they can understand the value you bring, renewed energy from your team around tangible progress,
and then maybe some peace. I love this mental peace after removing the noise and frustration of busy work, overwork, and overwhelming charts, which is like the definition of most data leaders I talk with. Noise and frustration of busy work, overwork, and overwhelming charts and graphs
about what success is and the progress of their team. So if this has been interesting to you, if this is a compelling framework, interesting framework, and something that you see would benefit your team, that you need a definition of success. Currently you don't have one or you have an overwhelming one or you have just been hoping for the best and trusting your gut. If you want to explore this framework in depth, I do have an offer that I'm putting together.
Measuring success launch pad. And what it looks like is in two weeks we can work through this framework and deliver success for your team, define and measure what success looks like for your team. And so let me show you what this, how this breaks down. The measuring success launch pad helps you define and measure peak success on your data team in just two weeks so you can execute, prioritize,
and get noticed by leadership like never before. So defining peak success, measuring it in two weeks so you can execute, prioritize, and get noticed by leader. And here's how the program will work over the course of two weeks. First off we do a strategy session and that's working with myself. We call it, I call it the strategy of success 90 minute session and this is where we do the bulk of the outline of the defining metrics for destination, waypoint, turn signals, and gauges template.
All right so that's the strategy of success. That's step one in this process is getting clarity on those and starting to work through. Then next you do a take-home exercise in this workbook or this workshop. You do this take-home exercise, takes you a couple hours where you identify the incentives that are at play and how the metrics that you are you defined during the strategy of success session, how those are going to show up on your team, and are they the incentives
that you want. Next we'll do a define and design and define session. This is our 90 minute session where we get into the weeds now about how these metrics are going to, what shape, color, texture they're going to have and how they're going to be operationalized in your organization and in your team. And after that you have a communicating success template and this is another take-home exercise that you'll do on your own one to two hours of work again where you're basically working through a
template of how to communicate success. A template for how to communicate success to your leadership. Take home that step four. Finally there's our 30 minute meeting where we work together to finalize and launch. So we review all your work, answer any final questions, make sure you have everything you need to launch out these metrics and start operationalize success for your team. So I have room to work with three data teams this summer through the measuring success launch
pattern really across these five steps. And if that's interesting to you, if this framework looks like something that would benefit your team and you need this clarity and confidence as a leader, reach out, send me a DM, drop me an email if this is something you'd like to work with. I have room to work with three data teams this summer on this framework. This is called the measuring success launch pattern.