The Skill That Follows You From Dashboard to SOC

Every cyber-career video says it's the soft skills. Almost none of them tell you what good actually looks like. Here's the version I can show you.

Recently, in a healthcare data role, I caught something that shouldn't have made it through. A vendor had returned results for a District of Columbia recertification campaign, and the numbers didn't sit right. So I reconciled thousands of submitted records against what came back and traced the discrepancies to their sources: inconsistent schema headers, test records that had slipped into production data, missing fields.

Finding it was the easy part. The part that actually mattered — the part that changed anything — was what came next. I had to take that finding to three different rooms: internal stakeholders, the vendor, and the District. Same failure, three completely different translations. The outcome wasn't a slide deck that got nodded at and filed. The vendor automated its process, and the recurring errors stopped.

That's the whole thing I want to talk about. Because I've been watching a stack of cybersecurity career videos lately, and they all land in the same place — it's the soft skills — and almost none of them stop to answer the question that actually helps you: what does good even look like?

I can answer that one. Not because I've spent ten years in a SOC, but because I've spent ten-plus years doing what I just described — taking something technically correct and getting a human being who doesn't speak my language to act on it. That's the same skill a SOC runs on. It just wears different clothes.

First, let's rename it

"Soft skills" is a terrible name. It makes the thing sound optional — a bonus you sprinkle on top of the real, technical work. That framing is exactly why so many analysts undervalue it, and why it reads as filler on a resume instead of the thing that closed the loop.

Here's the reframe. The schema failures I found were worthless as a finding until three different audiences understood them well enough to act. A perfect dashboard nobody acts on is worthless. A beautiful anomaly-detection pipeline nobody escalates is worthless — in the same way. The technical work only counts once it changes what somebody decides to do next.

The whole game

The difference between a skill you can NAME and one you can SHOW.

So I don't call it soft skills. I call it the translation layer: turning technically-correct output into a decision a real person will actually make. "Communication" is the ultimate name-only line on a resume. Everybody claims it. Almost nobody demonstrates it. This whole post is about moving it from the first column to the second.

The same finding, translated three ways

Go back to that recertification campaign, because it's the clearest example I've got of why this isn't one skill — it's a handful of specific moves.

The vendor needed the technical specifics: here are the exact schema headers that don't match, here are the test records sitting in your production data, here's the field that's dropping. Precision, so they could fix the root cause.

The District needed the impact: here's what these errors mean for the recertification campaign and the people it touches. Not a schema lecture — a consequence they could weigh.

The internal stakeholders needed the risk and the plan: here's how far this reaches, here's what we're doing about it, here's when it's resolved.

One investigation. Three translations. That is the translation layer doing its entire job — and it maps directly onto a SOC, where the same finding goes to a tier-2 analyst, to leadership, and sometimes to a non-technical business owner, each needing a different version of the truth.

Three more translations you're already doing

Alert → Escalation. This is the translation above, under pressure — a clock running and a plausible wrong answer on the table.

Weak: You escalate everything, or you sit on something real because you're not sure.

Strong: You hand someone a finding they'lltrust fast, with just enough context to act and nothing that slows them down. The credibility work — ruling out the obvious false read before you flag it —is the escalation.

Finding → Executive Summary.

Weak: You report everything you found, in the order you found it.

Strong: You compress to the one thing they need, at the top, in a paragraph a director reads and immediately gets.

I once walked through how a SIEM funnels tens of millions of raw events down to a handful of real tickets. That funnel is the same discipline as a good exec summary: ruthless compression that never drops the load-bearing fact.

Uncertainty → Honest Confidence. The one nobody teaches, and maybe the most valuable.

Weak: You overclaim ("this is definitely malicious"), or you freeze because you can't be 100% sure.

Strong: "Here's what I know, here's what I don't, here's my read and why."

I came up in atmospheric science, where you never had 100% certainty — the whole craft was communicating probability in a way that still drove a decision. That's not a hedge. In a SOC, where overconfidence gets people burned, and paralysis lets threats sit, being able to say "my read is X, here's my confidence, here's what would change my mind" is exactly what a good incident commander wants from you.

The spoken version

Everything so far has been the written translation layer. But there's a spoken version, and I built that one long before I touched healthcare data.

In my master's, I defended a thesis on air-quality forecasting — a room of experts whose job that afternoon was to find the crack in my reasoning, and mine was to walk them through it in a clear, steady voice. That's the same skill as briefing a room during an incident, or defending your read to a senior analyst who's testing it on purpose. Explaining technical work to people who will push back, without losing the thread or your composure — a SOC needs that as much as any dashboard-to-stakeholder handoff does.

Why / where / how

I write about tools this way, so I'll write about this the same way — because the translation layer is a tool.

WHY it's on the job req. This isn't a nice-to-have someone invented for LinkedIn. It's in the postings, in plain language: communicate complex technical issues to non-technical stakeholders clearly, and translate technical findings into actionable recommendations. As one breakdown of the role puts it, all that monitoring and analysis does little if other teams don't know what to do with the findings. When a req says "communicate to technical and non-technical stakeholders," that recertification story — vendor, District, internal, three translations — is the literal thing they're asking you to prove.

WHERE to build it — free. You don't need a lab or a license for this one. Write up your own analysis and force yourself to lead with the so what. Practice one-paragraph incident summaries on lab data. Explain a finding out loud to someone who doesn't work in tech and watch where their eyes glaze — that's your weak spot, live. Blog the reasoning, which, yes, is literally what I'm doing right now. Every writeup is a rep.

HOW to prove it in a portfolio. This is where name-only becomes show. A README a recruiter actually understands. A writeup with a clear "here's what this means and what I'd do." A one-paragraph executive summary pinned to the top of a repo, above the technical detail. When a hiring manager opens your work and gets it in thirty seconds, you haven't told them you can communicate — you've shown them. That's the difference the whole post is about.

The tool changes, the question doesn't

Here's the throughline, and the reason I can write this at all. Forecasting was never really about the data. It was about getting a person to change what they'd do next based on something I could see coming that they couldn't. Weather to healthcare analytics to network threat hunting — the tool in my hands kept changing. The question never did: what did you see, and what should I do about it?

The recertification finding was that same question wearing a healthcare badge. An escalation in a SOC is that same question wearing a security badge. If you're a data analyst eyeing a move into cyber and you're worried you don't "look technical enough" yet — hear this. The translation layer is the hardest part of this job to teach, and you've been practicing it for years without calling it that. You're not starting over. You're carrying the hardest skill in the door with you.

The tool changes. The question doesn't. 💜

If this is the reassurance you needed, the Foundations Workbook walks through how to turn skills you can name into skills you can show — starting with the ones you already have.

Get The Foundations Workbook 👉🏽