Tech Lead - Android Experience Engineering

Architecture & technical direction

• Own the technical architecture for your squad's domain - system design, API contracts, data models, integration patterns, and the Architectural Decision Records that document why.
  
• Enforce the Watu engineering standards within your squad: GitHub for all code, mandatory PR review, coverage gates, OpenAPI documentation, runbooks, and secrets management.
  
• Be the squad's representative to the Platform General Architecture - escalate cross-squad concerns, contribute to shared standards, and ensure your squad's patterns align with the broader platform direction.
  

Delivery & quality

• Review and approve all pull requests for your squad. Not as a bottleneck, but as the quality gate. Your name is on everything that ships.
  
• Define and maintain the squad's Definition of Done. Work with the embedded QA engineer to ensure quality is built in, not bolted on.
  
• Own the squad's release process. Nothing ships without your sign-off - including work from external partners where applicable.
  
• Drive sprint planning with the Product Owner - translate user stories into technical tasks, surface dependencies, flag risks early.
  

Partner & vendor governance

• Where your squad governs an external partner, you are the technical point of accountability. The partner executes; you govern. Architecture decisions, code quality, and release timing are owned internally.
  
• Review partner code via PR access. Nothing a partner ships enters production without your review.
  

People management (light but real)

• You have 4-6 direct reports: typically 1–2 Backend Engineers, 1–2 Frontend/Mobile Engineers, and 1-2 QA Engineers. They report to you for day-to-day work; the QA Chapter Lead reports to the Head of Engineering for standards but to you operationally.
  
• Unblock engineers actively - pair on hard problems, review designs before they build, and create an environment where asking for help is normal and fast.
  
• Give direct, timely feedback to your direct reports. Engineer growth happens through clear, specific feedback delivered close to the moment - not through annual cycles. You are the primary person responsible for the development of the engineers in your squad.
  
• Your input into performance reviews and hiring decisions carries significant weight - the Head of Engineering will lean heavily on your assessment of each engineer in your squad.
  
• Model AI-native engineering. Every engineer in your squad is expected to use AI/LLM tools actively. You set the tone for what that looks like in practice.
  

Essential

• 7+ years of software engineering experience, with at least 2 years where you were the de facto technical authority for a significant product area or team.
  
• Strong backend engineering fundamentals: distributed systems, event-driven architecture, API design, database design, and testing strategy.
  
• Proven ability to review and reason about code across the full stack of your domain - you can give a meaningful review on any PR your squad raises.
  
• Experience in an Agile/Scrum or Kanban environment where you drove sprint ceremonies, backlog refinement, and delivery alongside a Product Owner.
  
• Clear, direct communicator - with engineers, with Product, and upward to the Head of Engineering.
  

Strongly preferred

• Experience in fintech, payments, or digital financial services in Africa, LATAM or APAC.
  
• Experience governing external engineering partners or SaaS vendor integrations.
  
• Hands-on experience with Java backend development (our primary backend language).
  
• Familiarity with event-driven architecture, Kafka or equivalent message brokers.
  

Engineering standards you are expected to uphold

• All code in GitHub - mandatory peer review, unified branching strategy, green CI before merge.
  
• APIs documented with OpenAPI/Swagger; Architecture Decision Records for significant decisions.
  
• No secrets in code - AWS Secrets Manager or Vault. OWASP Top 10 awareness is a baseline expectation.
  
• AI/LLM tooling used actively in your daily workflow - code generation, test writing, documentation, debugging.
  

This role is NOT right for you if

• You want to be shielded from difficult technical decisions by a more senior architect above you. There isn't one at this level.
  
• You want to move away from technical work. You will have several direct reports and real people management responsibilities - but you will also be the most technical person in the squad. If the goal is to stop writing code and reviewing architecture, this is the wrong step.
  
• You prefer to work independently and find code review and pair programming friction rather than value.