The worst thing you can do to a team of experts is make them explain themselves in a language designed for amateurs.
A while back, a red team friend asked in a group chat how to handle management pushing agile on their offensive security team. My answer got really long really quickly.
Since red team management and practice leadership is my bread and butter, I have a lot of experience with fielding the sort of misguided idealism about KPIs and “stories” that comes from disconnected executives who mistake familiarity for wisdom, assuming that because one thing works somewhere, it must work everywhere.
What follows is a refined reproduction of my reply.
The first thing every project manager has to understand is that your app/platform/tool/whatever isn’t what gets the work done.
It isn’t the reason work doesn’t get done, deadlines get missed, or anyone misunderstood the requirements.
So changing the tooling every six months isn’t going to do anything except keep upper management off your ass because they usually don’t know better and annoy your team with more meaningless changes.
No end state, no solution.
It is the job of the project manager to define this and test whether it’s feasible with the people who will be executing the work.
Most of the time, especially in security consulting, the end result is outlined in a contract as a report or deliverable of some kind. For freeform projects like research efforts or tool development, replace the end result with an end state.
To do this well, you have to ask the right questions. What is the actual problem? How are we currently working and how do we want to be? Where are the bottlenecks?
Here are a few real-world examples from my career and the solutions my team came up with all on their own that were better than anything I could have come up with myself:
END STATE: We need a way to quickly and painlessly deploy access to client environments from which to conduct pentests.
SOLUTION: Vagrant VM templates that could be automatically uploaded to S3 for downloading by the client and, on boot, connected up to a Tailscale server and provided us remote access without the client having to punch holes in their firewall.
END STATE: $projectmanagementtool
doesn’t support natural language due date setting, which is crucial to
our project structures, so we need a way to deploy projects that saves
us from manually selecting a bunch of dates from shitty dropdown
menus.
SOLUTION: A custom Python script that builds projects entirely through $projectmanagementtool’s API.
END STATE: Our standard operating procedures for pentests (i.e., the bare minimum actions to take against a target) aren’t getting updated and therefore aren’t getting used.
SOLUTION: Make the SOP checklists the backbone for connected wiki articles so that new articles about vulnerabilities or exploit methods can’t be added without creating a reference in the SOP first.
If you can’t come up with a desired end state, your limitations become their constraints.
Bonus thought exercise: How many of the problems above have you seen “fixed” with a new product or piece of software?
Make your project templates freeing, not restrictive.
The most common types of projects your team works on should be templated and purely logistical.
Start date, end date, status update cadence, and that’s it. Everything else should be filled in by the practitioner. How they research, what they try, how they try it, etc. is all up to them. In a project management tool, that looks like this:
- Fieldwork Start + date
- Client Status Call + date
- Fieldwork End + date
- Report Draft to QA + date
- Report Draft Delivered + date
Quality isn’t a field in the template. It shows up in the work, or it doesn’t, and the status call is where that becomes everyone’s problem. This works really well for things like 5-day web app pentests that sales sends your way.
The less common, less rigid, and more freeform projects can still be templated as long as the template is purely logistical. Track what matters for the sake of billing milestones and contract terms. Leave the rest up to the experts doing the work.
A good attacker doesn’t need a script — they need a target and a scope. The rest is tradecraft. Give them enough constraints to ensure the delivery is to spec without suffocating them.
Pick a tool. Any tool. Stick to it.
Calendar events with notes, a project management tool, dedicated Slack threads, whatever. Just make sure everyone can go to the same place and see what the expectations are. Project management tools are references, not crutches. If you think a project management tool is going to make work easier, you’re delusional and avoiding the real problems.
Project managers should leave doers alone.
If you’re going to check in, build the check-in into the template upfront so it’s expected. Otherwise you’re just going to annoy everyone.
The person executing the work, or leading the project if there’s a team, is most likely going to come up with a better route or product than you could’ve come up with on your own.
Practitioners, especially hackers, tend to thrive with autonomy and room to experiment. Ask me how I know.
Learn to tell upper management to back off, politely.
Get desired end states from them, not dumb shit like “number of projects completed” or “number of tools integrated into methodology”. Ask them what they want to be able to say was accomplished.
What tangible improvements are they looking for? What gaps in the current product offering/security posture/etc. do they see that they want rectified? What are their true concerns?
This will help you cut through all the bullshit they heard on some podcast or from the board about “agile” and “story points” and get to the root of the problem, which is why the work needs to be done. Do not let them turn you against our boy Goodhart (opens in new tab) by making good measures into targets and, therefore, into bad measures.
Fix the communication problem, fix the project management problem.
People treat project management as some kind of equation to solve when it’s really just about communication.
The trouble is that communicating effectively is hard and requires more time spent on actually knowing, training, and trusting people than most companies have the time or energy for.
The irony is that it produces better outcomes than the alternative, just not the kind that light up a quarterly report.
Over time, taking this approach will make your team happier, give them more time to do what they’re actually good at, and outperform any version of this story where management got exactly what they asked for.
But be ready for upper management to see that and ask you to do 5-10% better year-over-year, killing the soul of your team for the shareholders.