In a particularly massive group chat I’m in, someone last week asked about how their team should deal with upper management pushing agile across the entire company. Their struggle came from their team not being developers but the in-house red team (hackers). Regardless, management was asking them to adopt Jira and run sprints, with reports on productivity expected to follow.
Naturally, I put the onus for implementing all of my suggestions on the team’s manager. Since red team management and practice leadership is my longest held and, according to LinkedIn, my most marketable position, I have a lot of experience with fielding the sort of misguided idealism about KPIs and “stories” that comes from disconnected executives who only have hammers and don’t believe anything exists but nails.
What follows is a mostly accurate reproduction of my rather long reply.
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. What I’ve found to work best is this:
All projects should have a desired end state.
All projects should have a desired end state. 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, this end result is outlined in a contract. The end result is a report or deliverable of some kind. Keeping this simple helps everyone. For freeform projects like research efforts or tool development, replace the end result with an end state.
One must, with no shortage of pedantry, distinguish between and end result and an end state for the sake of clarity among teams. Here are a few real-world examples from my career and the solutions my team came up with all on their own that exceeded my expectations and was 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, so we need them to
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 - not to be confused with a specific end result - then you’re part of the problem.
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 might look like this:
- Fieldwork Start + date
- Client Status Call + date
- Fieldwork End + date
- Report Draft to QA + date
- Report Draft Delivered + date
Whether it was adequate or sufficient will come out in status updates where others can weigh in. If you get to the deadline and it’s not what everyone expected, something got lost along the way. This works really well for things like 5-day web app pentests that sales sends your way.
The less common, rigid, or more freeform projects can still be templated as long as the template is purely logistical. Track what matters for the sake of billing milestones, contract terms, and generally being punctual. Leave the rest up to the experts doing the work.
You don’t tell an artist what colors they’re allowed to use, which brushes and chisels are most effective, or where their muse should come from. Give them enough constraints to ensure the delivery is to spec without suffocating them.
Track it all somewhere.
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 happen more easily, you’re delusional and avoiding the real problems.
Project managers should mostly be hands-off.
If you want to be involved, make it part of the logistical templating to be involved so everyone expects it when you try and check in. 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 via the process than you could’ve come up with at the beginning 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 fuck 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 weed 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 the root of 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.
Come up with your own way of doing things.
Try it, figure out the flaws, and fix them.
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, developing, and trusting people than most companies have the time or energy for because, though it may be more sustainable and powerful in the long run, it doesn’t as easily move the stock price because it doesn’t always translate to a brand new (half-baked) feature that doesn’t make a potential big client sign a contract that doesn’t bump revenue past last year’s numbers.
Over time, taking this approach will make your team happier, give them more time to do what they’re actually good at, and churn out better results than any tacked-on agile shit ever would have.
But be ready for upper management to see that and, despite the real reasons behind your success, ask you to do 5-10% better year-over-year, killing the soul of your team for the shareholders.