What Should I Work on Next? A Framework for High-Impact Security Work
“So, my last project is basically wrapped up. What should I work on next?”
This question comes up often in my 1:1s, and how I respond influences if my report will do high-impact work or spin their wheels. I believe among the most valuable things I do as a security engineering manager is steer my team towards the best work. When a security engineer looks to me for advice on what to work on, it’s a high leverage opportunity. I’ve succeeded by aligning people with work that mattered; I’ve also failed to recognize and redirect wasteful work energy. Over time, I’ve developed three criteria/questions to guide this discussion:
- Business Goals: What is the impact of this work on the business?
- Implicit Interest: How engaged are you when doing this work?
- Personal Growth: How much does this work align with your stated career interests?
Side-note: Decision making as an optimization problem
Back in 2012 at Twitter, I joined an internal group completing the Coursera “Machine Learning” course. One insight that stuck: behind all the matrix math, we were asking a hill climbing question. Given a bunch of dimensions, what are the best weights to predict outcomes?
That optimization mindset applies to simpler problems too, like “what to work on next”. Without a decision making rubric, you might jump to recent conversations with your boss, backlog items, or what would look good for promotion. Context is king so circumstances differ, but the best choice is unlikely to be based on just one criteria. The “right work” involves tradeoffs. Similar to “cheap/good/fast - pick two”, you can’t maximize everything. So, with that in mind, not all work will crush Business Goals, ignite Implicit Interests, and speed-run Personal Growth. But they’re all heuristics to consider for making optimal(-ish) choices about what to work on.
Business Goals
Information security isn’t a first-order business goal. While no company wants bad security outcomes, security work rarely moves the needle for top company metrics like revenue growth. Like other “platform” work and technical debt, it’s difficult to show direct value. As I mentioned in Building Effective Security OKRs, it’s easy to describe project value in ways that aren’t connected to business goals (“we shipped a thing”). Security engineers rarely explain their work’s value with spreadsheets full of numbers.
I’ve found one way to communicate security business value to stakeholders is through narrative. The story of why you’re doing what you’re doing needs to land with people thinking about business from the broadest perspective - executives, investors, customers, etc. The work may be a small part of this story. It may require explanation, and some squinting and hand waving. But work disconnected from business value won’t be watered and grown over time.
“Zero trust” is a narrative - “having network access shouldn’t get you access to services, there should be authentication/device verification involved”. There’s a deep risk discussion about why that’s good, but the narrative encodes it. Similar to “paved roads”, “detection engineering”, or “shift left” - these concepts connect projects to business goals via “strategy”. This is the connective tissue from grungy security work to IPOs/dollar signs.
Take static analysis tools as “shift left” thinking. The business narrative is preventing vulnerabilities before they become expensive bug bounty payouts or worse. But implementation details matter for that story to hold - you need the tool to catch vulnerability classes you’re paying for, not just generate noise engineers ignore. Similarly, when implementing detections, work backwards from credible threats people already understand - what’s in the news, what happened to similar companies - and tell the story from that threat-focused angle.
Some projects are inherently difficult to connect to business value. System rewrites (like migrating secret managers), building internal tooling that generates too many alerts to triage effectively, or access approval systems that slow productivity have very indirect customer impact. This is a problem many engineering leaders deal with, and selecting your portfolio is an art on itself. Suffice to say, it’s best to have clear examples of how you’re impacting users to offset the ennui around big projects where the successful outcome is “everything works like it did before”.
The other way security projects impact business is unlocking revenue through compliance and customer assurance. This may not excite security engineers the way a novel threat detection algorithm does, but it’s often the most direct path from security work to business value. When your SOC 2 Type II enables your first big enterprise deal or your FedRAMP certification opens government contracts, the ROI conversation becomes much easier. People focused on business outcomes recognize these compliance achievements as tangible value they can point to with customers and prospects.
Regardless of framing, workshopping a project’s business impact is a great way to prioritize it. How would you communicate the progress and outcome to the organization? If the message isn’t clearly “here’s how we’re driving our business forward”, take heed.
Implicit Interest
People prefer different types of work. One person may love diving into obscure technical challenges - a big “nerd snipe” target. Another may relish presenting to the organization about how security works. Others may be “red team” or “blue team”-coded.
The more someone gravitates toward and is absorbed by their work, the more productive they’ll be. Ask someone who dreads writing to complete a big documentation exercise, and it’ll take forever. Some engineers are allergic to frontend code. But find a problem that fits someone’s implicit interest, and they’ll often fly with it, bulldozing through obstacles and bringing unexpected creativity to problem solving.
Don’t forget you can combine people with complementary interests on the same project. Pair the person who loves prototyping with someone who enjoys writing thorough documentation. Match the frontend enthusiast with the API builder. This often produces better outcomes than forcing one person to do everything.
Given work with equal business value, figure out what project is more interesting. This is a great way to figure out if someone fits the team. If they’re not interested in the work, it’s hard to expect them to be more productive than a replacement who is.
Personal Growth
A final dimension to consider: how the work aligns with their stated career goals. A trap managers and reports fall into involves losing the plot about the report’s growth. If they don’t feel they’re headed in the direction they want at the pace they expect, their engagement and productivity will plummet while their departure becomes imminent.
If people know what they want to be when they grow up, connect the work they’re doing to that path. For engineers interested in the management track, prioritize work involving mentoring interns or working cross-functionally with other teams. For those who want to build their external presence, look for projects that could become “conference talk worthy” - novel approaches or interesting problems the broader security community would want to hear about.
In an ideal world, we’d all have deep clarity about how our career journey should unfold. Reality is that many people don’t know how they want to grow. Something like a career ladder can be useful as a default “here’s what growth looks like” description. Remember there’s no one true path for anyone’s career, and if you’re creative about how work can foster growth you can connect world-weary engineers with new challenges and kindle productive energy.
The world of security is broad and deep, and people are unique. Figuring out how to get the most of your team will continue to be the mark of effective security management. Use this three-part framework to evaluate options and get people onboard with winning projects.