Engineering Manager

Location: Fully Remote

Reports To: VP of Technology

Department: Product Development

FLSA Status: Exempt

As an Engineering Manager, you will own one product area from end to end: the team, the commitments, and the software running in production. You will lead by example to set the code quality bar, run the delivery rhythm, and mentor the engineers. Planet Depos has real engineering depth already, with strong architecture, a clean cloud estate, and sharp junior engineers; what this seat adds is the layer that uplevels those engineers to ship excellent code together into dated, delivered, operating software. You will partner with an embedded Product Manager in your area, and your team will own its services outright: building them, testing them, shipping them, and operating them.

Essential Job Responsibilities

• Stay hands-on: review pull requests, take real work, and know the codebase well enough to see where something is quietly going off course.
• Set the code quality and review bar across the team: non-author review on everything, patterns applied consistently, and no merges that skip review.
• Drive high and consistent architecture standards in partnership with the Group Architect.
• Own the team's commitments, so everyone carries a named owner, a reliable date, and a high-quality definition of done, with date adjustments always raised before the date arrives.
• Produce estimates with stated assumptions and a date the estimate gets refined, even under real uncertainty.
• Keep the systems of record current so status for the area is visible without anyone having to ask or chase.
• Run the team's ceremonies (planning, refinement, standup, retrospective) so each session exits with decisions, owners, and dates rather than open questions.
• Own the resolution of handoff items across development, QA, DevOps, and Product so work never stalls in an unowned gap.
• Manage external development partner contractors alongside the in-house team so their build integrates cleanly and no gap between teams stalls the work.
• Leverage agentic coding tools to audit code quality and drive efficiency without creating disorganization and fragility in the codebase.
• Manage the engineers as people: regular one-on-ones, coaching against what motivates each of them, honest performance feedback, expectations in writing when they are needed, and follow-through on both praise and consequences.
• Turn expert objection into forward motion: when a senior engineer says a plan will not work, drive to the alternative they can support, with a date and an owner.
• Ramp new engineers to independent contribution quickly and hold the team together through change.

Compensation Range & Benefits

$140,000 – $190,000 base compensation and bonus eligible, commensurate with experience. For a candidate who comes in at the Director of Engineering level, the range could be higher.

Benefits include Medical, Dental, and Vision coverage; Life insurance (Voluntary Term and Whole Life); Voluntary Long Term Disability; paid time off and paid holidays; 401(k); Employee Assistance Program (EAP); and Maternity Leave.

REQUIRED QUALIFICATIONS 

You must possess all four qualifications listed below. Candidates who possess only two or three qualifications will not be considered for the role. 

1. You communicate so well that it is where your team's efficiency comes from 

You write the update nobody must decode; you run the meeting that converges instead of sprawling, and you can carry the same message up to leadership and down to an engineer without either one losing the thread. This is listed first deliberately: at this team size, communication is the skill that compounds, and it is where most of the available efficiency lives. 

Qualifying experiences include: 

• A recurring written or verbal status practice you personally established that replaced people chasing each other for information, and what changed measurably once it was running 
• A moment you had to deliver the same difficult message in both directions, to an executive and to the engineer whose work was affected, and how you kept both conversations honest 

2. You have made a team's delivery trustworthy, and you can show the before and after 

You have taken over a team whose dates were vague, slipping, or silently missed, and you built the operating system that fixed it: named owners, real definitions of done, a standing status surface, and re-forecasts that arrive before the deadline rather than after it. You can walk through the actual status surface you ran, and the measured improvement that followed, not a philosophy of delivery. 

Qualifying experiences include: 

• A team you inherited where delivery was not trusted, the specific mechanisms you installed, and the measured improvement in predictability that followed 
• A high-stakes commitment that was going to slip, where you re-forecast early and took options up and out before the date, so nothing arrived as a surprise 

3) You have managed senior, strong-willed engineers, and kept them 

You have been the people manager for engineers more tenured or technically deeper than you, including at least one who did not want to be managed. You know how to convert "this will not work here" into a written alternative the expert will own, how to set expectations in writing, and how to have the hard conversation while it is still a coaching conversation. You have carried a team through a reorganization or a leadership change with retention intact. 

Qualifying experiences include: 

• A senior engineer who was blocking or disengaged from a change, the specific way you moved them to constructive ownership, and what happened to the team afterward 
• A reorganization or leadership transition you led a team through, what you did deliberately so it read as investment rather than threat, and the retention outcome 

4) You still have the technical depth to see problems before they surface 

You built and shipped software before you managed, and you have kept enough depth to be useful in the code today. You can follow a principal-level argument, ask the question that exposes the real tradeoff, and tell a genuine constraint from a preference dressed up as one. You know which calls are yours (priorities, dates, process, people) and which belong to architecture and platform, and you back those standards with your authority rather than competing with them. 

Qualifying experiences include: 

• A technical dispute between senior engineers that you refereed to a durable decision: how you separated the engineering substance from the ownership question, who made the final call, and why it stuck 
• A quality standard you enforced against resistance from someone senior, what it cost in the moment, and what it bought the team afterward 

Experience anchor. Two or more years as a front-line engineering manager, on top of hands-on engineering experience, with a team you can describe concretely: "I managed six developers, here is what we shipped, here is what I changed about how we worked." This is not a seat for a strong individual contributor stepping into management for the first time. Treat the anchor as orientation rather than a hard gate; the four qualifications above are the real bar, and demonstrated delivery substitutes for any specific credential. 

Buy-in on AI-assisted engineering is required. A track record of shipping AI features is not. You do not need to have built AI products, but you do need to already believe that AI-assisted development changes how software gets built, and to be someone we can hand an agentic workflow to without a blank stare. 

PREFERRED QUALIFICATIONS 

• Experience in a build-it, test-it, own-it, operate-it model, where the team carried its own services into production rather than handing them to a separate operations group 
• Experience coordinating an external or offshore development partner alongside an in-house team 
• Current hands-on ability in our stack: TypeScript (primary) and Java; Vue and React; AWS (ECS, Lambda, Aurora, DocumentDB, EventBridge, SQS, S3); PostgreSQL, DocumentDB, Redis, and SQL Server in the legacy estate 
• Clean architecture, Domain-Driven Design, event-driven systems, or SOLID discipline held across a team in production 
• Having managed through a reorganization, a leadership change, or a legacy-to-modern replatform 
• Prior work in a regulated industry such as legal, healthcare, or financial services