Software Engineering Team Manager

This is a senior role leading engineering for our content team's delivery pillar: the platforms that take authored content and delivers it to learners and instructors in every Pearson line of business. You will manage the teams that own:

• the content repository, player, partner-distribution, and learning-analytics platform.
• delivery services that serve finished content to Pearson's learner-facing products.
• the pipelines that handle conversions
• semantic enrichment

Most of the backend across these teams is Java, largely on Spring Boot, with Type Script and React front ends, and MongoDB as support. The systems are distributed and multi-region.

We are looking for a manager who runs these teams and is still close enough to the code to review it. You will own delivery, the growth and health of the engineers, and the technical standard the teams are held to. You will manage backend and frontend engineers at mixed levels across several time zones, including offshore partner colleagues, and you will work closely with the product leads and the technical leads for each platform.

The codebases are mature and if you are looking for a role where you translate between the teams and the business without touching the systems, this is not that role.

• Run the teams day to day: one-to-ones, goal setting, performance and growth conversations, and career development for engineers at mixed levels.
• Hire. Write the screen, run the interviews, and make the call. Each hire should raise the standard rather than fill a seat.
• Set the standard for design and code review across the teams, and hold it when a deadline is close. Review is where quality is actually enforced here. You will review Java pull requests yourself, distinguish code that is sound and maintainable from code that only appears to work, and explain the difference clearly enough that the author's next change is better.
• Grow the engineers who will make the technical calls after you. Make the leads stronger instead of becoming everyone's single point of judgment.
• Keep the teams' coding standards current. Recommend modern Java and Spring Boot practice, including current LTS language features, framework conventions, static analysis, and dependency hygiene. Write the standards down, and apply them consistently in review rather than only in a document.

• Own the shape of each platform: service boundaries, API contracts, data ownership, and the line between application code and shared library code.
• Define what  adequately tested  means for a backend service and for a React component, and enforce it. A test that only restates the implementation does not count.
• Own security in practice, not in principle: OAuth 2 and OIDC flows, JWT and JWKS handling, launch-token signing and verification, field-level encryption of personal data, and secrets through AWS Secrets Manager and KMS. Personal data stays out of the logs.
• Own resilience and operability. Retries, timeouts, circuit breakers, distributed locking, health checks, and instrumentation good enough that someone can diagnose a production problem without attaching a debugger.
• Treat accessibility and localization as part of a feature being finished. WCAG 2.1 AA conformance, keyboard and screen-reader behavior, focus management, and copy that survives a translation doubling its length are requirements, not follow-up tickets.
• Keep performance measurable. Bundle size and content-load time in the player, query and index design in MongoDB, and results you can state in numbers.
• Own dependency and vulnerability response: triage advisories, decide upgrade paths, and keep version pinning deliberate rather than accidental.
• Drive business continuity and disaster recovery for the services the teams own, including the drill and the closing of its findings.

• Turn product requirements into increments the teams can actually ship, and give estimates you are willing to be held to later.
• Push back when a proposed API contract, requirement, or date will produce a bad experience or a system nobody can support. Say no with a reason, or say later with a plan.
• Partner with the technical leads on each team rather than going around them, and with platform and product colleagues across the group.
• Stay hands-on. You will read and review code often.

• 7 or more years building production software as an engineer, and 3 or more years managing software engineers directly. That includes hiring,…