Who are Port Swigger
Port Swigger exists to enable the world to secure the web. We build the tools practitioners trust, the knowledge that trains security professionals, and a community that makes anyone who cares about security better - so anyone can make the internet safer. Our products are crafted with care, backed by deep research, and we lead through generous innovation: winning by setting the bar higher and sharing what we create, turning commercial success into wider positive impact.
Our culture didn't happen by accident - it was built deliberately, and it's something we protect with the same care we put into everything we make. We default to trust - brilliant people doing brilliant work, free from micromanagement. We aim for excellence, and we do it with care; performance and compassion go hand in hand. Joy, mastery and purpose belong together here - and if the work stops feeling good, we take that seriously.
Growth is our commercial engine: bringing new customers on board, keeping them delighted, and telling our story to the market. Growth is split into Sales, Customer Experience (Relationship Management, Customer Success and Tech Support), Marketing and Special Ops - collectively owning pipeline, retention, advocacy and the go-to-market playbooks that scale Port Swigger.
What you'll be doing
A renewal conversation turns painful long before it shows up in a Q . It usually starts months earlier - in a rollout that never quite launched, a feature nobody adopted, or a security team that quietly stopped logging in. By the time anyone's discussing it formally, the account team is negotiating from a position they should never have been in.
This role exists to read those signals early enough to still change the outcome.
You'll own a portfolio of Port Swigger's most technically demanding enterprise accounts, watching usage data, support patterns and stalled deployments for the moment something needs a person, not a dashboard. Sometimes that's you - diagnosing a broken SAML integration or a CI/CD pipeline that's only half-wired to Burp. Sometimes it's knowing exactly when to pull in a Solutions Architect or another specialist, and staying accountable for the outcome either way.
No two weeks look quite the same, but you'll regularly find yourself:
Pulled into a rollout that's stalled for reasons nobody's pinned down yet - a SAML config that's subtly wrong, an API integration that's 90% finished, a scan that was never actually scheduled - and getting hands-on until it's fixed, or the customer's own engineers can fix it themselves.
Reading the account health data - usage, support tickets, renewal timing - to spot the account that's gone quiet before anyone else notices, and deciding what actually needs to happen next.
Explaining the same technical issue three different ways in the same week: to a developer who wants the detail, a security leader who wants the risk, and an executive who wants the plan.
Spotting a champion who's gone quiet inside an account, and working out fast whether that's a stalled project you can unblock yourself, or a signal Sales and Renewals need to hear about now rather than next quarter.
Turning a one-off save into something reusable - a playbook, a script, a written-up approach - so the next TAM who hits the same problem doesn't have to solve it from scratch.
Whatever the account, you'll get into the technical detail, own the outcome, and leave the next person's job a little easier than you found it. Most TAM roles ask you to pick a lane - technical or commercial, hands-on or strategic. This one is built so you don't have to: you'll carry real technical weight and real account accountability in the same job, with the judgement to know which one a given moment actually needs.
You're credible in a room of engineers and just as credible in a room of leaders - and you know how to be both without performing either. Put a customer's architecture in front of you and you start asking the right questions: where the identity provider sits, what's actually going wrong in that API integration, why a scan never got scheduled.
You don't need to own every fix yourself, but you're not intimidated by getting hands-on with one.
You're comfortable enough with code and scripting to build a small tool, read CI/CD script pipelines or work out where a deployment pipeline is quietly broken. Networks, identity, cloud infrastructure and how services actually talk to each other aren't a foreign language to you. Port Swigger's own…
(If this job is in fact in your jurisdiction, then you may be using a Proxy or VPN to access this site, and to progress further, you should change your connectivity to another mobile device or PC).