The Engineer’s Edge: Soft Skills, AI, and Career Growth in Cybersecurity

Last month, I gave my first talk at BSides Charlotte. The topic wasn’t a technical deep-dive on a specific tool or attack vector. It was about something I think gets undervalued at security conferences: the operational and human side of doing cybersecurity work well.

I’ve been meaning to write this up since the talk — here’s the full version. The ideas that came up that day have shaped almost every team conversation, client engagement, and hiring decision I’ve been involved with. So I wanted to get them down properly — both as a reference for the engineers we work with and for anyone thinking about what it actually takes to grow in this field.

https://www.youtube.com/watch?v=oPLaqiu7PM8

The full talk is above. Below is the written version, expanded where it’s useful.

Start with the customer experience

One of my favorite quotes, not from a keynote, just something Steve Jobs said in passing — is this: “You have to start with the customer experience and work backwards to the technology.”

Early in my career, I did the opposite. I’d get excited about the latest tool, CrowdStrike versus SentinelOne, Azure versus AWS, ThreatLocker versus everything else, and try to find clients to fit into it. The technology came first; the customer came second. I learned, slowly and sometimes painfully, that this is backwards.

The best solution for a client is rarely the most technically impressive one. It’s the one that actually fits their operations, their budget, their team’s capability, and their risk tolerance. That requires understanding the business before proposing the technology, every time.

I use a slide scale analogy for this in conversations with clients. On one end: maximum security. On the other end: maximum convenience. Both extremes are wrong. Lock things down so tight that nobody can work, and you’ve protected the business from breaches while destroying its ability to generate revenue. Leave everything open for the sake of convenience, and a breach does the same damage anyway. The job is to find where the slider belongs for each specific client, and that requires actually understanding how they operate, not just what tools you want to deploy.

“I don’t have time” is not what you think it means

One of the most common things I hear from engineers, and something I said myself until a mentor called me on it, is “I didn’t have time for that” or “I’ve been too busy.”

Here’s what that actually means: that task wasn’t high enough on your priority list.

We all have the same 24 hours. We all roughly know how many of those hours we’re going to work. We all have some visibility into what needs to get done. Saying “I didn’t have time” is technically untrue, what’s true is that something else ranked higher and this thing ranked lower, whether or not you made that decision consciously.

In cybersecurity and MSP environments, this matters more than in most fields. Missing or delaying response to a security incident by five, ten, or twenty minutes can be the difference between a contained alert and a compromised environment. The discipline of explicit triage, writing down every open item, ordering them by actual priority, and working through that order deliberately, isn’t a productivity hack. It’s how you avoid letting urgency masquerade as busyness while something important goes unaddressed.

AI as a force multiplier, not a shortcut

AI is reshaping how we work day-to-day, and I don’t think that’s slowing down anytime soon. But the framing that matters most: AI is a force multiplier for the skills you already have. It’s not a replacement for building them.

Concrete example from the talk: a client needed an inventory of which folders in a two-terabyte data set had active data versus cold storage, how much was in each, when it was last touched. I could have hacked together a Python or PowerShell script over a few hours. Instead, I described the problem to ChatGPT, got a working script in five minutes, validated it against what I knew about how the code should work, and moved on. That’s the right use of AI, using it to get past a barrier faster, not using it to avoid understanding the barrier at all.

Other places we’re using AI right now: summarizing meeting transcripts from Microsoft Teams (who was there, what was discussed, what the action items were and who owned them), formatting client-facing communications, and drafting documentation. Every one of those is a task where the underlying judgment still has to come from a human, AI just removes the friction of producing the artifact.

If you’re in a technical role and not actively experimenting with how AI can extend what you’re already capable of, you’re leaving real capacity on the table. And if you’re using it as a substitute for building skills rather than an amplifier for them, the limits will show up eventually.

Situational awareness: knowing what you don’t know

One of the slides in the talk said “know what you don’t know,” and I always get questions on that one because it sounds like an oxymoron. What I mean is: when a ticket or incident comes in, self-assess before diving in. Is this something you’re genuinely equipped to handle? Or is this something where five hours of research might mean a real threat has five hours to run unchecked?

Engineers, especially in cybersecurity, tend to be natural problem-solvers. We want to figure things out. We’re comfortable with ambiguity, and we enjoy learning. That instinct is valuable almost everywhere except when there’s a live incident and a client on the other end waiting for a response.

In those moments, the right move is often to raise your hand early. “I need help on this one” or “this needs to go to someone with more context on this type of incident” isn’t a failure. It’s good operational judgment. The caveat: stay involved. Ask what happened after you escalate. Follow up with the person who took it. That’s how you build the depth to handle it yourself next time.

The flip side of situational awareness is recognizing patterns in recurring issues. If the same alert keeps coming in and you keep clearing it, ask why it keeps coming in. A band-aid applied repeatedly isn’t a fix, it’s a sign there’s a root cause worth finding. The engineers who develop the instinct for this, who notice patterns and push to eliminate them rather than just clear the queue, are the ones who tend to advance fastest. Less reactive work, better outcomes for clients, more interesting work for everyone.

Lean forward. Communicate. Don’t make people wonder.

One of the practical things I’ve drilled into every team I’ve managed is this: lean forward on communication. Especially when you’re waiting on something.

In IT and cybersecurity, a lot of us are more comfortable in async text-based communication than on the phone. That’s fine. But the people we support, clients, end users, business owners, often aren’t. They don’t live in ticketing systems and Slack channels. When something is broken and nobody’s calling them back, they’re not thinking “the team must be working on it.” They’re thinking “nobody’s doing anything.”

A straightforward example from the talk: our office internet went out. I called the ISP, they gave me a resolution time of 3pm. Three o’clock passed. Four, five, still down. No call, no update. I eventually had to chase them. Even if the delay was completely unavoidable, the absence of communication turned a technical problem into a frustration problem. It didn’t have to be.

The fix is simple. Communicate early and often. Set an expectation, then update it if it changes before the other person has to ask. In our ticketing system, we always write a “Next Step” at the bottom of every ticket note, abbreviated “NS” — so that anyone picking up the ticket can immediately see what the current plan is without having to call anyone. No ambiguity, no dropped balls, no wondering.

There’s a line from The Dark Knight that I referenced in the talk: “no one panics when things go according to plan.” That’s genuinely true. People handle bad news and delays fine when they know what to expect. What makes them anxious is uncertainty. Your job is to remove the uncertainty, not just solve the problem.

The career ladder: owners, not renters

The last section of the talk was about career progression, and it’s the part I wish someone had told me clearly when I was starting out.

The typical path at most MSP or cybersecurity firms looks something like this: SOC analyst or help desk → team lead → engineer → senior engineer → management, if that’s where you want to go. Each level has different responsibilities, different stakes, and requires a different mindset.

At the analyst level, you’re learning the work, triaging alerts, handling help desk requests, and beginning to understand what normal looks like. At the team lead level, you’re filtering between the desk and the engineering team, handling escalations, and starting to teach. At the engineer level, the stakes go up significantly. You’re making recommendations that clients take as gospel. You’re working on real businesses with real revenue. You can’t wing it.

Management is its own track and not for everyone, and that’s completely fine. But if you’re considering it, the mental reframe that helped me most is this: management is still problem-solving. You’re just solving people problems and process problems instead of technical ones. Same muscle, different application. Often harder, for what it’s worth.

How to get promoted: do the job before you have it

Nobody is going to walk up to a level-one analyst and say “you seem smart, let me spend money training you and move you up.” It doesn’t work that way. You have to start doing the next role before anyone officially gives it to you.

For me, the first step was volunteering for weekend projects. Server upgrades, network migrations, anything that got me working alongside the senior engineers on the team. Two things happened: my managers noticed I was willing to step up, and I started building real working relationships with the engineers I wanted to learn from. Those relationships became informal mentorships. Those mentorships led to getting included in higher-level work. That exposure is how I got the next role before anyone officially created it for me.

A few other things that actually move the needle:

• Become the subject matter expert on one tool or system on your team. Nobody’s stopping you from learning it deeply, writing internal documentation, and becoming the go-to person for it. That expertise is visible and valued.
• Don’t gatekeep knowledge. The engineer who hoards information to seem indispensable is usually the first to go. The one who shares, teaches, and makes the team better is the one who gets promoted.
• Raise your hand for uncomfortable things. Growth happens at the edge of your comfort zone, not in the middle of it.
• One hand up, one hand down. As you advance, look for ways to pull someone else along with you. Teaching reinforces your own understanding and builds leadership credibility.

The throughline

The throughline across all of this is something I believe pretty deeply: the technical part of this work is the easy part. Not because it’s simple, it isn’t, but because technical problems have right answers. You can look things up, test, iterate, and get there.

The hard parts are operational. Getting buy-in from a client who doesn’t want to change their password policy. Communicating clearly when something goes wrong. Knowing when to escalate instead of dig in. Building a team that moves in the same direction. Those are the skills that separate good technical people from great ones, and they’re almost never taught explicitly.

That’s what the talk was about. And it’s part of what we try to build into how Rival IT operates, both in how we work with clients and in how we develop the team.