Use Signal Mapping to Turn Data Into Action
Signal Mapping is a practice of pairing a signal that is rooted in data to a specific action. You can think of it as saying the sentence "When I see X data I will take Y action."
It's a simple method I developed years ago when I hit the problem so many others do of not knowing what to do or what data to look at. When I started experimenting with WIP limits, I asked the team to use their cycle time as a signal it was working. It helped them through the struggle and let them see the benefit: they were shipping in 1/3rd of the time. Signal Mapping became a way to frame up decisions and pair them to data that acted as signals to act upon.
You can of course think of this as simply a traffic signal. The light acts as a signal that prompts action. The difference is we were taught the mapping explicitly as stopping at a red light.
Why Use Signal Mapping?
Most folks are drowning in data, reports, metrics, and dashboards but struggle to find the insights they need to take specific action. The data they have isn't helping. Maybe they've been burned in the past by taking an incorrect action, or presenting what the data shows is going to hurt their career. It could also be as simple as: the data tells no useful story whatsoever and is just numerical static.
The problem boils down to there being too much data, but none of it helps inform what actions to take.
Signal Mapping is how you can fix that. If you want to be a more data-informed leader, this is a great way to build that practice up and it will work for the rest of your career. As you mature in the practice your signals will mature as well.
So, if you want to grow your ability to use data to inform your actions, Signal Mapping is where to start.
Also, when you need to advocate for a specific course of action or change of course, presenting data as evidence is a huge help. Signal Mapping will teach you how to connect data back to meaning in a way that will make your case stronger. I should note though, that when you make your case to others, presenting your signals is not likely going to be enough and will often invite lots of questions and skepticism. This is because most leaders are not fluent with using data themselves and you'll need to be prepared for this.
Step 1: Start With Decisions and Questions
I find the easiest way to start with Signal Mapping is to start with the actions, decisions, or questions you need to answer. For fun, you can read a beekeeping example to see how it works outside of software engineering.
You'll likely be drawn to either specific actions or decisions or questions as the way you think through this, and that is totally fine. I'll give some examples of common ones below to get you started.
Team Decisions
- Do I need to add someone?
- Do I need to remove someone?
- Would purchasing this tool help?
- Is someone going to quit soon?
- Are there morale issues I need to fix?
- Is my team stuck?
- Where do they need help?
Project Decisions
- Are peer/dependent groups ready?
- Is the plan ready enough to work on?
- How will we mark or celebrate important milestones?
- Will this risk be a problem?
- Are we late?
- When do we need to adjust the plan?
- Should we give another team work?
- Should we take work from another team?
Technical Decisions
- Is our technical debt under control?
- Are our costs within acceptable ranges?
- Are our systems operationally sound?
- What NFRs need to change?
- What quality hotspots need work?
Leadership and Strategy
- Are we making progress on a strategic initiative?
- Do we need to change course?
- Who else from the company do I need to bring in?
- What meetings should I defer or delegate?
- How much more budget do I need?
- What outcomes should we be tracking or presenting?
Hopefully you get the idea. I framed these as questions, and it's alright if you frame them as specific actions or decisions.
Some of these, you'll notice, happen at very different cadences with very different levels of importance. That's life. With all new practices you want to get repetitions in so even if you want your most important decisions protected with Signal Mapping, start more frequent ones to hone your skills.
Once you've made a list of questions and decisions, you're ready for step two.
Step 2: Ask, "What Do I Need to See?"
Now for the hard part. For each decision you need to ask yourself, "What would I need to see that would prompt me to act?" Easy right?
Okay, you're likely going to feel a sense that there are too many choices and none of them are perfect. You'll have a lot of what-ifs that talk you out of everything. Quiet that part of your brain down for a minute and let me finish.
Signal Mapping is about developing useful indicators that prompt action. All that means is that it is enough for you to act, not prove anything.
"But what if I'm wrong?" That's the next step, but there is something to pay attention to. Even if you're partially wrong, you'll also be partially right. You'll learn to refine things as you go. This process offers feedback to you that will sharpen your ability to develop signals. You'll be alright.
Also, these signals can be private. In fact, a lot of them will naturally be private. So while you get the hang of it, nobody will know why you did what you did.
Alright, now what you're looking for when you answer this question is something you can actually observe. Feelings are observable, but you'll need to add some rigor to it. I want to give an example right here that might help when I say these are indicators that are observable and personal.
"When I see people express interest in other jobs 2 times in 1:1s in a month, then I need to focus on morale."
I use something very close to this. Hopefully you can see what I've been writing about in this one example. I can observe what folks talk about in their 1:1s with me and count them up. I decided that 2 times in a month is enough of an indicator to act on morale. What specific actions I'll take isn't decided yet but I know my effort will be spent there.
Step 3: Act and Refine
The final step is straightforward enough. Keep your signals close-at-hand so you can keep them updated and act on them. If we look at the example above, I need a place somewhere to tally that sentiment that came up in 1:1s.
Now, when you hit your signal you're going to experience something. You probably won't enjoy it. You are likely going to experience profound doubt and skepticism. This is the beginning of feedback on how you use Signal Mapping.
The first thing to realize is that those feelings are not facts themselves, but a signal to you. The signal isn't that things are wrong, but that you're unsure. Use the moment to ask again, "What would I need to observe?" In this moment you might find something that will refine your thinking. The goal, however, isn't to make your feelings stop. You're simply taking advantage of the moment.
Consider a leader who is always in fire-fighting mode. They apply Signal Mapping to put an end to all the emergencies. The first signal goes off before an emergency. They are hit with a wave of doubt. Their signal is prompting them to act before an emergency happens but this is so unnatural that it feels wrong to act this early. If this leader acted on those feelings of doubt, they'd miss the window to prevent the emergencies like they'd hoped.
The feeling is a signal to reflect, but do not treat that feeling as a fact that things aren't working.
Now you can take the actions needed. Again when you're done, you can look back and alter what is needed. I mentioned above you'll get some of it wrong, but get other parts right. Celebrate the win, refine, and move forward.
When Signal Mapping Fails
Let's be honest, there are no silver bullets and Signal Mapping has flaws. Signal Mapping works best for leaders to guide their decision making privately. Using this in public-facing ways can be tricky and can backfire.
If you want to use Signal Mapping with your teams or on projects publicly, everyone needs to buy into those signals as indicators. This is a challenging conversation as everyone will have their own idea and nobody will believe each other's work. Getting a leadership team to develop and agree on what their signals are and what they mean is exactly the work of my Measures, Metrics, and Signals workshop. It exists because this conversation rarely succeeds without structure.
Still, a useful place to try this is around operational thresholds. Take things like server capacity. It is usually straightforward to do Signal Mapping to say, "When we observe we are at 85% disk capacity, we will then upgrade it."
Frequently Asked Questions
What is Signal Mapping?
Signal Mapping is a practice of pairing data to a specific action by completing the sentence, "When I see X, I will take Y action." Instead of collecting more metrics and hoping insight appears, you start from the decisions you need to make and work backward to the few things you need to observe.
Is Signal Mapping a Metrics Framework like DORA or SPACE?
No. Frameworks tell you what to measure, but not what you should do. Signal Mapping tells you when to act. It works alongside any metrics you already have, including DORA, and it works with no formal metrics at all. If your dashboards are full but your decisions aren't any easier, the missing piece is the mapping, not another framework.
What is the Difference between a Metric and a Signal?
A metric is data with meaning imposed upon it, like velocity means productivity. A signal is data with an action attached to it. "When I see interest in other jobs come up twice in a month of 1:1s, I focus on morale" is a signal. Signals serve as indicators that it's time to act.
Do I Need Dashboards or Special Tools to Use Signal Mapping?
No. Signals only need to be observable, and many of the best ones come from things you already see, like what comes up in 1:1s. A tally in a notebook works. Many of your signals will stay private to you, which means you can build the practice without anyone's permission.
If this kind of straight talk is useful, I write a short letter every Friday. Stories, tips, techniques, and the occasional bits of beekeeping. Join it below.
Read More
- How to Measure Developer Productivity: How to measure developer productivity without wrecking your team. Measure the system and team, not the person. What Google's frameworks actually measure, and what changes when AI writes the code.
- Why DORA Metrics Are Bad: DORA metrics aren't bad, but the worship is. What the four metrics can and can't tell you, how teams game them, DORA vs SPACE, and what to build instead.
- Get Started With Dev And Product Metrics: There is a ton of heartburn about metrics, so in this article I explain how to start with metrics for any development group in a healthy way.
- One Metric To Start: -