About the role
This is a hands-on engineering manager role on a small team. You will spend most of your week on people, planning and review, and the rest in the codebase, enough to review a pull request properly and to know when an estimate is fiction.
The team works in thin end-to-end slices: each one ships and can be verified on its own, rather than a backend phase followed by a frontend phase. Your main lever is how you cut that work, because a slice that is too wide is how quality quietly disappears.
You will also own the quality bar in a domain where a wrong value can hurt someone. That means holding the line on review discipline and test coverage when there is pressure to ship, and being the person who says a feature is not done because it only worked once.
What you'd do
- Break product goals into slices that each ship and can be verified on their own
- Hold the quality bar: review discipline, a real test suite, and no feature called done because it worked once
- Hire, onboard and grow engineers; run one-to-ones and make the calls on scope and sequencing
- Keep the roadmap honest about what is built versus what is planned
- Own delivery communication: what shipped, what slipped, and why, without decoration
What we need
- Eight or more years in software, at least two of them leading engineers directly
- You still read and review code, and you can say when you last wrote some
- A track record of shipping on a regular cadence with a small team, not just running a large one
- You have hired engineers and can describe a hiring decision you got wrong and what you changed
- Comfortable making the call when the data is incomplete, and saying so out loud
Nice to have, not required
- You have managed in a regulated or safety-critical domain
- Experience taking a product from its first customers to its first ten
- You have run an on-call rotation that people did not dread
How we work
- Small team, thin slices, shipped weekly. Nothing sits on a branch for a month.
- Reviews are real. Every feature ships with its tests, and a bug found in review is cheaper than one found by a customer.
- Safety-critical means the boring answer usually wins: fail closed, keep the receipt, don't guess.
- We only claim what ships. That applies to the product, the roadmap and the offer letter.
How hiring works
- 1A 30-minute call about something you've built and what was hard about it.
- 2A working session on a real problem from this codebase. You can drive, or we can pair.
- 3A conversation about how you make decisions when the evidence is thin.
- 4References, then an offer. We aim to answer within a week at every stage.