Senior Engineering Manager, Postman

• 10+ years in software engineering, with 5+ years leading engineering teams
• Depth you can prove on a hard technical problem you personally solved — a system you designed and debugged yourself, not a project you oversaw. We will ask you to go deep on this
• Experience taking a validated product from 1→10 — scaling something that already had customers into something a large organization standardizes on. This is not a 0→1 role; the interesting problems here are breadth, scale, and trust rather than product discovery
• Production ownership of an enterprise integration surface at breadth — many third-party providers, each with its own authentication, rate limits, permission model, and cloud-versus-self-hosted differences. You've felt the maintenance cost of the tenth connector
• Demonstrated ability to ship work that depends on teams you don't manage, in an organization where those teams have their own roadmaps
• Experience leading a senior-heavy team, where the job was elevating strong engineers rather than directing junior ones
• Multi-tenant enterprise SaaS, including customers with on-prem or self-managed infrastructure and real compliance requirements
• Full lifecycle ownership from design through production support
• Clear, economical communication with engineers, executives, and customers. You'll be in front of all three

Desirable

• A large enterprise runs hundreds of services across multiple cloud accounts, multiple gateways, several repository hosts, and a mix of cloud and on-prem infrastructure. Nobody can produce a complete list. Postman's API Catalog is the system of record that can: it connects to where APIs actually live, brings them into a single inventory, and gives platform teams the means to govern them — ownership, environments, specification compliance, and evidence that release gates were met
• What's ahead is: turning a product that works into the system of record that a large platform organization standardizes on company-wide. That means carrying estates an order of magnitude larger than today's, reaching every environment and every gateway an enterprise actually runs, and becoming the control plane through which API governance happens rather than one more inventory somebody has to maintain
• We're hiring a Senior Engineering Manager to own the engineering behind it. You'll lead a small, senior, US-based team, and you'll spend a meaningful share of your time landing work that crosses team boundaries — because most of what this roadmap needs, this team does not build alone
• Service discovery and ingestion breadth. Connecting to the systems where APIs are defined and deployed — repository providers across cloud and self-hosted, cloud API gateways, and clusters. Breadth is the growth axis: each provider we support is an enterprise we can serve
• Enterprise reporting and governance evidence. Test and CI-pipeline reporting, specification linting, and the records enterprises use to prove a release met its gates. Trust is the product here; a number a customer can't reconcile is worse than no number at all
• Gateway federation. Large organizations don't run one gateway; they run several, from different vendors, across many accounts, often with different teams owning each. Federating that estate into a single governed view — and doing it without asking customers to reorganize around us — is one of the defining technical problems of this product's next phase
• Event-driven API support. Extending the catalog beyond request/response to event technologies — beginning with Kafka, end to end from client through specification and governance into the catalog
• Product maturity, reliability, and telemetry. Metrics you can trust as a single source of truth, a support flow that doesn't consume the roadmap, and datastore reliability that doesn't produce customer-visible incidents. This is treated as a first-class investment area, not overhead
• The API Catalog owns the system of record: how services are discovered, ingested, federated, linked to environments, governed, and reported on
• Manage, coach, and grow a team of experienced engineers, some of whom hold institutional knowledge that predates you. The work is surfacing gaps and raising the bar, then letting senior engineers own the fix
• Hire deliberately as the team grows, and set a clear technical bar in the process
• Set explicit goals, give direct feedback, and keep the team's work legible to the rest of the organization
• Reduce single-owner concentration on critical systems. Spread context deliberately rather than letting it pool in one person
• Most of what the catalog ships depends on teams you don't manage — specification tooling, the API client, the integrations and ecosystem teams that own provider connectivity, and shared platform services. You'll need to secure commitments, sequence around other teams' plans, and unblock reviews without escalating every time
• Own the seams: define the contracts between the catalog and its dependencies clearly enough that both sides can move independently
• Be honest and early about which commitments are genuinely at the mercy of another team's roadmap, and bring options rather than only the blocker
• Drive architecture and execution across ingestion, federation, the service model, and the reporting and deployment data layers, with correctness, multi-tenant isolation, and cost-per-tenant as design constraints rather than afterthoughts
• Set the quality bar for reporting accuracy and build the measurement to know whether you're meeting it. A number a customer can't reconcile is worse than no number
• Treat on-prem and self-managed deployments as a first-class variant of every connector, not a port
• Hold the line on engineering fundamentals — design review, testing, safe staged rollout, and instrumentation of the team's own services
• Own the API Catalog engineering roadmap and its tradeoffs, balancing enterprise commitments, connector breadth, and debt in systems that predate the current product direction
• Break large initiatives into milestones that ship incrementally and can be evaluated on the way. Several of this team's initiatives will mature beyond a single quarter; plan accordingly
• Own production reliability and the support burden, and treat recurring toil as a design problem rather than a staffing one