Senior Engineering Manager (Member Experience)

• We are hiring a Senior Engineering Manager to own a significant piece of Omada’s Member-facing surface. You own what gets built, in what order, and how the people building it grow
• A squad owns problems from prototype to production, including the maintenance and the on-call rotation for what it ships. At this level you own more than one, which means the hardest calls you make are the ones about where capacity goes when two good things want it at the same time
• You stay technical. You are in the codebase and in the same agent workflows your builders use, close enough to review architecture, catch a weak design, and be useful in an incident. Where you manage directly, you ship production work off the critical path. Where you manage through someone else, that person’s growth is your work product
• You partner with Product Strategists who spend their time in front of members, coaches, and stakeholders, and who prototype to test ideas quickly. They own what gets built and why. You own whether it can be delivered, at what cost, and by when, and you are senior enough that your answer shapes the roadmap rather than just responding to it
• Own delivery across your squads. Sprint shaping, prioritization, backlog grooming, and estimation. Make the calls, write them down, and be accountable for them. When two squads want the same thing at the same time, you are the one who decides
• Own cycle time. Yours to improve, not at the expense of quality, and yours to explain when it changes, including why one of your squads is slower than the other
• Stay technical. On squads you manage directly, you ship production work every sprint, off the critical path, in the same agent workflows your builders use. On squads that run through a manager, you stay close enough to review architecture, catch a weak design, and be useful in an incident. Either way, you can teach someone to navigate the system, not just navigate it yourself
• Partner with your Product Strategist. They own what the squad builds; you hold the line between their scope and yours so the squad never has two people answering the same question differently
• Grow a manager. If an EM reports to you, their growth is your work product. Their squad’s health is the evidence
• Plan the team you need next year, not just this quarter. Headcount, skill mix, and the onboarding path that gets a new builder productive in an agent-heavy codebase in weeks rather than months
• Set the AI standard past your own boundary. Write down what good looks like, teach it, and measure whether it stuck. Other squads should be able to use what you built without you in the room
• Take on the problem that is nobody’s. You will find things that slow down engineering broadly. Some of them you should pick up, organize, and close out with your peers
• Technologies we use:
• Ruby on Rails, Python (Flask, FastAPI), React, native iOS (Swift, SwiftUI), native Android (Kotlin), PostgreSQL, GraphQL, AWS (RDS, SQS), Docker, Kubernetes, GitLab, Datadog, PagerDuty

Benefits

• Remote first
• Flexible vacation
• Wellness days
• Parental leave
• Omada program
• Resources to thrive
• Meeting-free days- You are comfortable being accountable for what your squads ship. You still write code, and you want to. This role ships production work off the critical path, in the same codebase and the same agent workflows as your squads, so you feel the friction your people feel first-hand
• You have a point of view on where AI-assisted development helps and where it creates rework, and it comes from changing how a real team works, not from reading about it. You have done the engineering manager job well enough that you can teach it. Whether or not you have carried the title of manager-of-managers, you have grown someone into leading, and you know the difference between doing the work for them and raising their ceiling
• Your first team is your peer group, not your reports. When something is slowing down the engineering org and it is nobody’s job, you have a track record of picking it up, getting the right people in the room, and finishing it
• Experience developing another leader: a manager who reported to you, or an engineer you grew into a tech lead or EM role with real accountability attached. Tell us where they are now
• A track record shipping mission-critical software to production, and living with it afterwards. We all make mistakes; what sets you apart is that you own yours and turn them into something better
• Experience owning prioritization and estimation for a team, including saying no, not now, and explaining why
• Currently shipping, or recently shipping, production code in at least one layer of our stack (backend (Ruby, Python, …), web frontends (React), iOS, or Android,) with enough range to follow the conversation in the others and review architecture decisions critically
• Understanding of CI/CD, logging, monitoring, and telemetry, at the level where you can tell whether your squad’s operational story checks out or falls short
• Experience giving direct developmental feedback, and at least one case where you managed someone through underperformance with real support attached
• 8+ years in software engineering, including 4+ years managing engineers directly
• Hands-on experience directing AI agents through real world production changes, and a considered view on where they help and where they produce work someone else has to redo
• Comfort with an expert-generalist team model, where a backend-heavy builder ships in the mobile app and a mobile-heavy one ships in the backend. You understand how transformative this model is, and you should be able to name the risks and opportunities it brings
• Excellent written communication. Much of this job is writing things down clearly once so they do not have to be argued four times