•Own major features end to end, working closely with our design team — from the decision through to release. This is real delivery, not oversight
•Own, maintain, and improve reliability metrics for key features
•Review pull requests and give the kind of feedback people learn from, not just approval
•Unblock the team: notice when someone has been stuck on the same thing for two days, and go take a look yourself
•Notice when something one person built should become the version the team uses, and see that change through
•Keep the shared pieces in working order — tested, clear enough for someone else to pick up, and consolidated when three versions of the same thing appear
•Call it when the team is ready to change how it works, rather than waiting for that to happen on its own
•Reduce how much manual intervention it takes to get a correct release out
•When the same problem shows up twice, get the underlying setup changed so there isn't a third time
•Shift verification left: grow what can be checked automatically so the nightly build going to QA is a confirmation rather than the first time anyone finds out
•Run planning so the team's attention goes to the work that still needs decisions rather than the work that's already clear
•Work out how much review each area needs, and where a person always signs off regardless
•Participate in discussions across Product, Design, and Engineering, and bring the team's constraints into those rooms early
•Handle critical issues, own feature releases, and provide nightly builds for the QA team
•Make sure the people early in their careers are getting work they can learn from, and the time to learn from it
Some of your engineers will be skeptical about parts of how the team is asked to work. In our experience that skepticism tends to be specific and worth acting on, and the people raising it are often the right ones to hand the underlying problem to.
An Ideal Candidate Should Have
•5+ years of software engineering experience, including time leading a team or owning a major surface while staying hands-on
•Rock solid Kotlin, Kotlin Coroutines, Kotlin Flow, Dagger 2, MVVM, Clean Architecture, Background Services, Music Player Service, Android animations, Jetpack Navigation, and JUnit tests
•Experience shipping and maintaining background audio or other long-running background work
•Understanding of the importance of tests and how to approach writing them, including what can't be covered by them
•Something you introduced to a team that stuck after you stopped pushing it, and an honest account of what it cost to get there
•Some comfort with the unpopular half of the job: asking people to change how they work, and living with the friction that follows
•A view on which changes need heavy review and which don't, argued from what the system does
•A track record of building things the rest of your team actually used, not only things that made you faster
•The ability to describe how your team works with AI agents, not only how you do personally
•Product design intuition, user empathy, and the drive to push Android UI/UX further than the spec asks for
•Self-drive to improve the app and codebase beyond what's outlined in the spec
•Excellent communication skills
