Week 14: What I Wish Someone Had Told Me
Twelve weeks ago, we started this series talking about a gap in how people learn security work. You can get certified, read the frameworks, know the technical fundamentals—and still walk into your first real security role completely unprepared for how the work actually functions.
Nobody teaches you the organizational part. The political part. The part where your technically perfect solution dies in a budget meeting. The part where you discover that half your environment isn’t documented and everyone just works around it.
We’ve spent twelve weeks filling that gap. Talking about the realities that textbooks don’t cover and certifications don’t test for. The organizational dynamics, the political navigation, the pragmatic trade-offs, the gap between theory and practice.
These are the things I wish someone had told me earlier in my career. Or maybe they did try to tell me, and I wasn’t ready to hear it yet. Sometimes the lesson doesn’t land until you’ve seen enough to recognize what it means.
Some of this I learned through mistakes—my own and others’. Some through painful experience during incidents, failed projects, and organizational friction. Some through watching seasoned practitioners navigate situations I didn’t understand yet. And some through finally understanding what a mentor or manager had been trying to tell me for months, once I had the context to make sense of it.
I can’t give you the experience—that you have to earn yourself. Experience is what engrains these lessons in ways that reading never can.
But what I can give you is context. Frameworks for understanding what you’re experiencing, so the lessons land faster and with less confusion. Explanations for why your boss, your manager, your lead, your VP does the things they do—not because they’re wrong or don’t care about security, but because they’re operating with constraints and pressures you might not see yet.
And maybe—hopefully—this series will help reduce some of the stress. The frustration of proposing good ideas that go nowhere. The confusion when leadership makes decisions that seem obviously wrong. The exhaustion of fighting battles that never seem to end.
If you understand the organizational dynamics, the political realities, the resource constraints, the competing priorities—it doesn’t make the work easy, but it makes it make sense. And when it makes sense, you can try different approaches. Different framing. Different timing. Different tactics.
You’ll have tools, techniques, and methods to try when your first approach doesn’t get traction. Not because the first approach was wrong, but because you’ll understand why it didn’t work and what might work better given the specific organizational context you’re in.
The work is still hard. But understanding why it’s hard—and having strategies for navigating that difficulty—makes it sustainable in ways that just grinding through without context never is.
I can’t give you the experience—that you have to earn yourself. But I can give you the framework for understanding what you’re experiencing, so the lessons land faster and hurt less.
THE PATTERNS THAT KEPT APPEARING
If you’ve been following this series from the beginning, you noticed certain themes surfacing repeatedly. That wasn’t accidental. These are the patterns that underpin how security work actually gets done:
Understanding before securing. We started with asset inventory and environmental knowledge (Week 1) because you can’t protect what you don’t know exists. But that principle echoed through every subsequent week. You can’t manage risk in systems you haven’t inventoried. You can’t build detection for attacks you have no visibility into. You can’t secure identities you haven’t cataloged. You can’t assess vendor risk without understanding what access they have. You can’t navigate organizational politics if you don’t understand the business context.
It all starts with understanding what you’re actually working with. Not what the documentation says. Not what people think is there. What’s actually there.
Fort Knox isn’t the goal. We covered this explicitly in Week 2, but it came up again in Week 7 (why security projects fail), Week 10 (when best practices don’t apply), and everywhere we talked about pragmatic trade-offs. Perfect security is impossible and often counterproductive. Your job is managing risk proportionally within realistic constraints, not eliminating all risk.
Learning to calibrate your risk tolerance to organizational reality—to distinguish between “this is dangerous and unacceptable” and “this is uncomfortable but pragmatic given our constraints”—that’s professional growth. It’s also what prevents burnout when you realize you can’t achieve the textbook ideal.
Documentation is operational, not bureaucratic. I recommended starting a risk register in Week 1, and it kept proving useful throughout the series—critical in Week 2, essential in Week 6, valuable again in Weeks 10 and 11. It’s not compliance theater.
It’s how you track what you’ve found, what the organization has accepted, what you’re working on, and what you’re carrying forward. It’s how you demonstrate progress over time. It’s how you protect yourself from inheriting responsibility for decisions made years before you arrived.
But it’s also a working tool for prioritization. When you choose a risk assessment methodology—and we didn’t cover that in this series, but you’ll need one—your risk register becomes the map that shows you what to address first, what to tackle next, what’s lower priority but still needs eventual attention. It helps you move the program forward strategically instead of just reacting to whatever’s loudest or most recent.
Without it, you’re operating from memory and reacting to pressure. With it, you have a coherent view of your security posture and a rational basis for prioritizing work.
When someone asks “what security issues do we have,” you have an answer. When leadership accepts a risk you’re uncomfortable with, you document it and move on. When you’re trying to show improvement year over year, you have the receipts.
Incremental progress beats perfect plans. This showed up everywhere—Week 2’s risk management, Week 7’s project failures, Week 10’s pragmatic trade-offs. You won’t fix everything at once. You won’t get unlimited resources. You won’t have perfect organizational support. But consistent, demonstrable improvement over time? That’s achievable. That’s what separates effective security practitioners from people who burn out fighting for impossible standards.
Close ten risks this quarter. Close twelve next quarter. That’s progress. The risk register still has 150 items? Sure. But it had 172 six months ago. You’re moving in the right direction.
And here’s the thing: not all 150 items are critical. If they are, you probably need to revisit how you rank and categorize risks—your methodology might be inflating everything. More likely, the majority are actually lower risk. They’re still risks you need to treat (compensating controls where possible, documentation where you can’t), but they’re not drop-everything urgent.
Look at what you actually closed: this quarter, 12 items—half were critical, 2 were medium, 4 were low. Prior quarter, maybe you closed 10 items—3 critical, 5 medium, 2 low.
That’s tangible risk reduction in a short period of time. You’re not just moving items off a list—you’re systematically reducing your organization’s exposure to the risks that actually matter most. The critical findings are getting addressed. The high-severity gaps are closing. The attack surface is shrinking in the areas that count.
That’s the kind of progress leadership can understand and you can be proud of. And it’s only visible if you’re tracking it properly.
Organizational literacy matters as much as technical skill. Understanding how decisions get made, who influences them, what pressures leadership faces, how to communicate in business terms, when to fight and when to document and move on—these came up in Week 6 (reporting through IT), Week 7 (why projects fail), Week 8 (reading the room), and honestly everywhere.
Technical competence gets you in the door. Organizational effectiveness determines whether you can actually get security work done. You can be the smartest security person in the room and still accomplish nothing if you don’t understand how to operate in the organization you’re actually in.
Vendor promises and reality rarely align. Week 5 covered this extensively, but it echoed in Week 3’s visibility gaps and Week 4’s identity sprawl. Whether it’s logging capabilities, incident response commitments, authentication mechanisms, or SLA definitions—verify everything, get commitments in writing, plan for failure.
This isn’t cynicism. It’s professionalism. Vendors are businesses with business objectives. Their incentives aren’t perfectly aligned with yours. Understanding that dynamic helps you manage the relationship effectively instead of being repeatedly surprised when they don’t deliver what you expected.
Compliance and security aren’t the same thing. Week 9 made this explicit, but the tension appeared in Week 6 (using compliance as a forcing function), Week 8 (understanding what your CISO actually cares about), and Week 10 (when best practices don’t apply). Passing an audit doesn’t mean you’re secure. Compliance frameworks test for specific controls at a point in time—they don’t evaluate your comprehensive risk posture.
But compliance requirements can be useful. They create forcing functions that get resources allocated. They provide deadlines that security risk assessments often don’t. Use them strategically, but don’t let them define your entire program.
Pattern recognition comes from repetition. Week 12 was about learning from public breaches, but the principle applies more broadly. After you see enough incidents, enough vendor failures, enough project dynamics, enough organizational patterns—you start recognizing them earlier. You develop intuition for what’s likely to succeed versus what’s going to struggle. You get better at predicting which risks matter and which ones are theoretical.
That intuition can’t be taught directly. But it can be accelerated by deliberately learning from others’ experiences instead of only your own.
WHAT WE DIDN’T COVER (AND WHY)
This series was never meant to be comprehensive. It was focused on a specific gap: the organizational and practical realities of security work that don’t get taught in formal programs.
We didn’t do technical deep-dives. How to configure a SIEM. How to write detection rules. How to perform threat modeling. How to implement zero trust architecture. Not because those aren’t important—they absolutely are—but because there are plenty of good resources for learning those things. The gap isn’t technical knowledge. It’s organizational context.
We didn’t do tool recommendations or vendor comparisons. Tools change constantly. What’s cutting-edge today is legacy tomorrow. The principles of what you need (visibility, detection, response capability, identity management) don’t change. The specific products that deliver those capabilities change all the time. Besides, the right tool depends on your environment, your constraints, your use cases—there’s no universal answer.
We didn’t cover advanced topics like threat hunting, red teaming, sophisticated detection engineering, or security research. Not because those aren’t valuable career paths, but because this series was aimed at people 1-5 years into security work who are still building foundational organizational literacy. Those advanced topics come later, and they build on the foundations we’ve covered here.
We didn’t go deep on specific compliance frameworks or regulations. GDPR, HIPAA, PCI-DSS, SOC 2, ISO 27001—the specifics vary, but the organizational dynamics we covered in Week 9 apply broadly. The tension between compliance and security, the way audits work, the importance of documentation, the scope boundaries—those patterns repeat regardless of which framework you’re working with.
We didn’t cover career progression, salary negotiation, resume building, interview preparation, or other career development topics. Important? Yes. But outside the scope of “how to actually do security work effectively once you’re in the role.”
The focus was deliberate: the organizational, political, and practical realities of security work that usually take a decade of painful experience to learn. Everything else—the technical skills, the tool knowledge, the advanced specializations—you can find elsewhere or will learn as you need them.
THE SKILLS THAT COMPOUND
Some skills plateau relatively quickly. You learn a technology, you get proficient, you maintain that proficiency. That’s valuable, but it doesn’t keep growing exponentially.
Other skills compound over time. They get more valuable the longer you practice them, and they apply across changing contexts even as technologies and tools evolve.
Communication skills compound. Learning to translate technical risk into business impact, to tailor messages for different audiences, to advocate for security work without being preachy or alarmist—these skills improve with practice and apply regardless of what security domain you’re working in or what technologies you’re using. Ten years from now, the specific security tools will be different. The need to communicate effectively with non-technical stakeholders will be exactly the same.
Organizational navigation skills compound. Understanding how decisions get made, building relationships with stakeholders, recognizing political dynamics, knowing when to push and when to document and move on—these get easier with experience and apply across different organizations and roles. You’re building pattern recognition for organizational behavior that transfers.
Judgment and prioritization skills compound. Learning to distinguish between critical risks and theoretical concerns, knowing what’s worth fighting for and what’s worth accepting, making intelligent trade-offs with imperfect information—this is the skill that separates senior practitioners from junior ones. It takes years to develop because it requires seeing enough situations to build reliable intuition.
Systems thinking compounds. Understanding how pieces fit together, recognizing second-order effects, seeing patterns across seemingly different problems—this improves continuously as you accumulate more context and experience. The person who can see how an identity sprawl problem (Week 4) connects to vendor risk (Week 5) connects to organizational structure (Week 6) connects to compliance requirements (Week 9) is thinking systemically. That’s a skill that develops over years and applies broadly.
Relationship building compounds. The trust you build with colleagues, the credibility you establish with leadership, the reputation you develop in your professional community—these accumulate over time and make future work easier. The security person who’s known for being reasonable, competent, and effective gets more organizational support than someone with identical technical skills but no relational capital.
Technical skills matter. You need them. But they’re also more volatile—what’s cutting-edge today is outdated in five years. The compounding skills we’ve focused on throughout this series? Those stay valuable throughout your entire career.
KNOWING WHEN TO STAY, WHEN TO MOVE
Not every organization is a good fit for every practitioner. And not every challenge is worth pushing through.
But let me be clear up front: this section isn’t about quitting security. It’s about recognizing when you need to move to a different organization to continue growing in this field. The work matters. You staying in this field matters. Sometimes that means finding an environment where you can actually do the work effectively.
Some situations are hard but developmental. You’re learning, building skills, making progress even if it’s slower than you’d like. The organization has constraints and you’re figuring out how to operate within them. Leadership isn’t perfect but they’re reachable. Resources are limited but you’re able to demonstrate value and make incremental improvements. You’re frustrated sometimes, but you can see a path forward.
That’s worth staying for. That’s where you build the organizational literacy and political skills that compound over time.
Other situations are hard in ways that aren’t developmental—they’re just dysfunctional. You’re hitting the same walls repeatedly. Security work gets killed for reasons that don’t make sense even after you understand the context. You’re excluded from decisions until it’s too late to influence them. Leadership says security matters but their actions show it doesn’t. You’re expected to accept responsibility without being given authority. Your professional opinions are solicited but never actually valued.
We talked about some of these patterns in Week 6 (reporting through IT leadership). The questions to ask yourself:
Are you making progress, or are you just spinning your wheels? If you’ve been trying the approaches we’ve covered—building relationships, communicating in business terms, demonstrating value, picking your battles—for a year or more and nothing is changing, that tells you something about whether the organization is actually ready to invest in security.
Is the situation challenging in ways that are building your skills, or is it just draining your energy without growth? There’s a difference between “this is hard but I’m learning how to navigate it” and “this is dysfunctional and I’m just absorbing damage.”
Have you had honest conversations with your management about the walls you’re hitting? Not venting, not just complaining—but explaining the specific obstacles and working together to figure out how to break them down or work around them. “Here’s what I’m trying to accomplish, here’s where I’m getting stuck, here’s what I’ve tried, what are your thoughts on how we might approach this differently?” Sometimes leadership doesn’t realize the structural barriers you’re facing. Sometimes they have context that explains why things are the way they are. Sometimes they can help remove obstacles if they understand what you need.
If you haven’t had those conversations, have them before you decide the situation is unfixable. But if you have had them—repeatedly, clearly, professionally—and nothing changes, that’s information.
Are the structural problems fixable, or are they fundamental to how the organization operates? Sometimes reporting structure can evolve as you demonstrate value. Sometimes organizational culture is so deeply rooted that one person can’t shift it, and trying will just burn you out.
Are you asking for perfection from an organization that’s comfortable with “good enough”? This is a real question you need to sit with. We talked in Week 2 about calibrating your risk tolerance to organizational reality. Some organizations aim for security maturity. Some organizations aim for “adequate enough not to get breached, and we’ll deal with it if we do.” Neither is inherently wrong—they’re different risk appetites serving different business strategies.
If you’re pushing for Fort Knox and the organization is comfortable with three locks and a guard dog, that’s a mismatch. Not necessarily because either of you is wrong, but because your expectations don’t align with their reality. That’s a conversation worth having with leadership explicitly: “What’s our actual goal here? Are we trying to be best-in-class, or are we trying to meet baseline requirements and regulatory obligations? I need to understand what success looks like for this organization so I can calibrate my work appropriately.”
Are you experiencing physical symptoms from the stress? Losing sleep, anxiety that persists outside work hours, health impacts—these are signals that the situation isn’t sustainable regardless of whether you’re learning. We mentioned this briefly in Week 6, but it’s worth repeating: no job is worth destroying your health. If the organizational dysfunction is affecting you physically, something has to change. Either the situation improves, or you need to be somewhere else.
The difference between “this is hard but worthwhile” and “this is damaging and I need to leave” isn’t always immediately clear. Give situations a fair chance. Use the strategies we’ve covered. Build skills and credibility. Have the hard conversations with management about what’s not working and how to improve it. Be honest with yourself about whether you’re asking for perfection or asking for basic functionality.
But also be honest about whether you’re making progress or just enduring dysfunction.
Moving to a different organization isn’t failure. Sometimes it’s the most professional choice you can make. The field needs you. If you’re in an environment that’s preventing you from growing or actively damaging you, finding a better fit is how you stay in this career long-term.
Don’t leave security. But don’t stay in situations that are breaking you, either.
THE MOMENTS THAT MAKE IT WORTHWHILE
Security work is hard. There will be days where everything you propose gets shot down. Weeks where you’re underwater on compliance requirements while actual security work gets deprioritized. Months where you’re fighting fires instead of making progress. Incidents that reveal gaps you knew existed but couldn’t get resourced to fix.
But there are also moments that make all of it worthwhile.
When you prevent something bad from happening—and maybe nobody else even knows. You caught the phishing campaign before it spread. You identified the misconfiguration before it was exploited. You flagged the vendor risk before it became a breach. The threat was real, you stopped it, and it never made headlines because that’s how good security works.
When leadership finally understands what you’ve been saying for months. You’ve been raising a risk, documenting it in your risk register, communicating it clearly. And finally—maybe because of a public breach that demonstrates the exact scenario you described, maybe because they’ve accumulated enough context, maybe because the timing is finally right—they get it. And they fund the remediation. That validation feels incredible.
When a process you built actually works during a crisis. The incident response plan you documented. The logging you fought to implement. The relationships you built across teams. The escalation paths you defined. When an actual incident happens and everything clicks into place—people know their roles, the documentation is there, the logs exist, the communication flows—that’s satisfying in ways that are hard to describe.
When you look at your risk register from a year ago and realize how much you’ve actually closed. Fifty risks remediated. A hundred issues addressed. Technical debt that existed for years, finally fixed. Controls that didn’t exist, now implemented. The work felt incremental day-to-day, but looking back across a year the progress is undeniable.
When a junior colleague comes to you with a problem and you can help because you’ve been there. You’ve navigated the same organizational friction. You’ve had the same conversation with that executive. You’ve solved the same technical challenge. And you can save them some of the pain you went through because someone’s finally asking the questions you wish you’d known to ask.
When you see evidence that security is becoming part of how the organization thinks, not just a checklist. Development teams including you in design reviews without being told to. Business units asking about security implications before making decisions. Leadership considering security risk alongside other factors instead of treating it as an afterthought. Culture change is slow, but when you see it happening it’s incredibly rewarding.
These moments don’t happen every day. Sometimes they don’t happen every month. But they do happen. And when they do, they erase a lot of the hard days.
The key is recognizing them when they happen and letting yourself feel good about them. Security success is often invisible—the things that don’t happen, the crises that never occur. Train yourself to notice and acknowledge the wins, even the quiet ones.
They’re what keep you going through the challenging stretches.
THE LONG GAME
Security careers are long. Measured in decades, not years.
Where you are right now—1-5 years in—you’re still building foundations. Learning the technologies, yes, but more importantly learning how organizations actually work. How decisions get made. How to communicate effectively. How to navigate politics without becoming political. How to make progress within constraints.
This phase is about building competence and credibility. Demonstrating that you understand the business, not just the security. Showing that you can work within realistic constraints, not just advocate for ideal solutions. Establishing relationships and reputation that will make future work easier.
At five years, you should have solid technical fundamentals and growing organizational literacy. You understand your environment well. You can identify risks and communicate them effectively. You can implement security controls and demonstrate their value. You’re starting to see patterns and develop intuition. You’re trusted to handle incidents competently.
At ten years, you should have strong pattern recognition across multiple domains. You can assess a security program and quickly identify the high-value improvements. You understand organizational dynamics well enough to navigate them strategically. You can mentor others effectively because you’ve seen enough to articulate the lessons clearly. You’re building security programs, not just implementing controls.
This isn’t about titles or hierarchy—it’s about capabilities and impact. The ten-year practitioner who’s built robust security programs in constrained environments has skills that compound indefinitely. The person who’s only chased certifications and job titles without building organizational effectiveness hasn’t grown the same way.
And here’s something nobody tells you early on: the work gets more satisfying as you get better at it. Not easier—it’s still hard—but more satisfying. Because you’re making bigger impact, seeing the long-term results of work you did years ago, mentoring people who are where you used to be, solving more complex problems that require the experience you’ve accumulated.
The first few years can be frustrating because you see all the gaps but you don’t have the organizational positioning or credibility to address them as fast as you want. That gap between what you know should happen and what you can actually make happen—it’s demoralizing sometimes.
But as you build competence, credibility, and organizational capital, that gap narrows. Not because the problems get easier, but because you get more effective at solving them.
This series covered twelve weeks of content, but it’s really about giving you frameworks for understanding the next decade. The organizational patterns, the political dynamics, the pragmatic trade-offs—these are things that typically take years of painful experience to learn.
You’ll still need the experience. But hopefully you’ll recognize what you’re experiencing more quickly, make better sense of it, and extract the lessons with less pain and confusion.
WHAT’S NEXT (AND WHAT YOU WANT TO HEAR ABOUT)
I’ve built two security programs from the ground up in different-sized companies. I’ve worked for major nationwide organizations and small operations. I’ve been the solo security person and I’ve been part of larger teams.
These twelve weeks covered the challenges I see most security practitioners face regardless of organization size—the foundational organizational and political realities that transcend specific industries or company stages.
But there are things I didn’t cover. Some because they felt too specific or too advanced for this series. Some because they’re skills I’ve internalized to the point where I don’t think about them consciously anymore—like systematic thinking and how I can hear one scenario, build out the attack vectors in my head, and mentally scroll through defense-in-depth layers to identify gaps. (Actually, that’s a topic we didn’t talk about at all, and maybe we should have.)
So here’s what I want to know: What are you facing that we didn’t cover?
What topics are top of mind for you right now? What organizational challenges are you hitting that don’t fit neatly into the twelve weeks we just went through? What skills do you wish you had better frameworks for understanding?
Maybe it’s how to think systematically about security architecture. Maybe it’s how to build a security culture when you’re not in a leadership position. Maybe it’s how to handle specific political dynamics we touched on but didn’t fully explore. Maybe it’s technical topics where you want the organizational context—not just “how to implement X” but “how to get X funded and adopted in a resistant organization.”
Maybe it’s something I’ve never thought about because my experience is different from yours, or because I’ve been doing it so long I don’t realize it’s not obvious.
I’m listening. What would be useful?
ONE LAST THING
You’re going to make mistakes. You’re going to advocate for things that don’t get funded. You’re going to miss things during incidents. You’re going to communicate risk poorly and watch decisions get made based on incomplete understanding. You’re going to implement controls that don’t work as well as you hoped. You’re going to accept trade-offs you’re uncomfortable with and occasionally rationalize things you shouldn’t.
That’s normal. That’s part of learning this work.
The difference between effective practitioners and struggling ones isn’t that effective practitioners don’t make mistakes—it’s that they treat mistakes as information. What didn’t work? Why? What would I do differently next time? What pattern am I seeing here that I should watch for in the future?
Every failed project teaches you something about organizational dynamics. Every incident reveals gaps in your defenses or your processes. Every awkward conversation with leadership shows you what resonates and what doesn’t. Every vendor disappointment calibrates your expectations.
The experience compounds if you let it. If you’re paying attention, reflecting, adjusting based on what you learn.
Security work matters. It matters for the organizations that depend on it. It matters for the people whose data you’re protecting. It matters for the broader ecosystem—every organization that gets breached makes the threat landscape worse for everyone else.
You’re building something worthwhile. Maybe not quickly. Maybe not perfectly. Maybe not with the resources you wish you had. But you’re building it.
The twelve weeks we’ve spent together covered a lot of ground. Environmental understanding, risk management, visibility gaps, identity sprawl, vendor relationships, organizational navigation, project dynamics, executive priorities, compliance tension, pragmatic trade-offs, incident response, and learning from others’ mistakes.
But really, it’s been about one thing: how to do security work effectively in the real world, with real constraints, with real people, in real organizations that are messy and imperfect and don’t match what the textbooks describe.
You know more now than you did thirteen weeks ago. Not just facts—frameworks for understanding the work you’re doing. Context for the challenges you’re facing. Strategies for operating more effectively. Patterns to watch for. Pitfalls to avoid.
The work is still hard. But you’re better equipped for it.
I wish someone had told me this stuff earlier. I’m glad I could tell you.
Now go build something.
The post Week 14: What I Wish Someone Had Told Me [https://cultivatingsecurity.com/ftnt-14-what-i-wish-someone-had-told-me-security/] appeared first on Cultivating Security [https://cultivatingsecurity.com].
