Principal Quality Engineer - praca zdalna

Firma LawnStarter szuka osoby na stanowisko Principal Quality Engineer: poziom kierowniczy, a więc odpowiedzialność za zespół albo za cały obszar. Oferta należy do kategorii „IT i programowanie” i jest w pełni zdalna. Firma nie ogranicza miejsca zamieszkania kandydata, więc zgłoszenie można wysłać z dowolnego miejsca.

Firma nie podała żadnej kwoty, ustala się to na rozmowie. Ogłoszenie nie stawia żadnych warunków co do godzin pracy.

Ta oferta przeszła automatyczną kontrolę: na listę nie trafiają ogłoszenia wymagające zagranicznego pozwolenia na pracę, sponsorowania wizy, określonego obywatelstwa ani zamieszkania we wskazanym kraju.

Headquarters: Mexico

URL: http://lawnstarter.com

About LawnStarter

LawnStarter is the nation's leading on-demand marketplace for lawn care and related services, with over $150M in annual bookings. We're expanding beyond lawn care to become the one-stop shop for all home services.

About Engineering Quality at LawnStarter

Our QA team is growing, and we're investing real money in better test coverage. We already have shared quality standards and a QA squad that organizes itself horizontally across teams. What we don't have is someone dedicated to owning that vision: every QA is heads-down on their own team, so nobody has the room to drive the standards forward, unify how the squad works, or push the state of the art. That's the gap this role fills. It's not a nice-to-have we're adding because things are going well. It's the structure and leadership we need to make what we've already built actually compound.

The Role

You'll be LawnStarter's first Principal Quality Engineer, reporting directly to the Head of Engineering. We already have quality standards, working CI/CD gates, and AI tooling in the mix. Nobody owns the vision behind all of it, drives it forward, or leads the QA squad that keeps it running. You will.

This isn't a QA management job today. You won't spend your day approving tickets or chasing bug counts. You'll take ownership of the standards and tooling that already exist, work collaboratively with the QA squad to improve them, and keep pushing the state of quality engineering forward as the org grows. As the QA squad grows, this role could take on direct people management of QAs, so hiring, coaching, and performance management experience is a real plus even though it's not the day-one job.

You're not starting from zero, and you're not inheriting a mess either. That means the job isn't "invent a strategy nobody has thought about." It's "listen to the QAs who live in this every day, understand where the pain is, and lead them toward what's next." We need someone who reads where LawnStarter is today and builds from there, not someone who shows up with a favorite tool stack and a coverage number they picked before they met the team.

What makes this role different:

* You own and evolve the quality strategy together with the QA team, instead of building one in a vacuum or just executing someone else's.

* You have direct sponsorship from the Head of Engineering and the room to keep growing the AI-native tooling already in the mix.

* Your success is measured by how much better the whole engineering org's quality gets under your leadership, not by a headcount number.

What You'll Own

* Strategy and vision : The company-wide quality engineering roadmap, plus a quality accountability framework that spells out what engineers, EMs, and PMs each own at every stage of building software.

* Test strategy across the stack : Unit, component, contract, API, end-to-end, mobile, and non-functional testing (performance, load, accessibility), agreed with each team as their quality contract.

* AI-native quality tooling : AI agents and skills, including Claude Code style tooling, that any engineer can run on demand for test generation, code review, and quality guidance. You'll keep hunting for the next AI capability worth putting in front of the team.

* CI/CD and test infrastructure : Required checks, quality gates, E2E and visual regression pipelines, performance budgets, and the mobile test automation strategy across emulators and real device clouds. That includes deciding what actually needs to block a deploy versus what can run async, and keeping the pipeline itself fast.

* Production quality signal : Tying monitoring into incident response and building dashboards teams actually check, not ones that just exist.

* Technical mentorship of the QA discipline : QA engineers keep reporting to their own Engineering Managers today. You won't manage their day-to-day or their careers right now. You'll own the technical and craft side of QA org-wide, mentor QA engineers across every squad, and send your input to their EMs to feed performance reviews. That could change as the squad grows into a direct reporting line to this role.

Problems to Solve

A solid quality bar with no one steering it.

We already have shared standards, working quality gates, and AI tooling in the mix. What's missing is someone whose job is to look at all of it, decide what needs to improve next, and actually drive that improvement instead of it being everyone's part-time responsibility.

A QA squad with no dedicated leadership.

Our QAs already organize horizontally across teams, but every one of them is focused on their own team's work day to day. Nobody has the bandwidth to unify how they work, spread what's working on one team to the others, or represent their pain points where decisions get made. You'll give that squad the structure and leadership it's missing.

Standards that need continuous R&D, not a rewrite.

The foundation works. The risk is standing still while the org grows. You'll keep pushing the state of the art, testing new approaches and tools, and deciding what's worth rolling out broadly versus what stays an experiment.

Quality work that's still someone's side project.

Right now, improving quality practice competes with each QA's day-to-day team commitments. You'll make it someone's actual job to carry that forward, and get engineers, EMs, and PMs treating it as planned work instead of something squeezed in.

What Success Looks Like (Year 1)

* A clear quality vision, owned and communicated : Every product team can point to what "good" means for their testing and why, with you as the person who set that direction and keeps it current.

* Measurable improvement on existing gates : Flakiness, pipeline cost, and what runs sync versus async on core repositories are visibly better than when you started, not just maintained.

* At least one new AI-native capability shipped : You've pushed the existing AI tooling forward with something new, like an added test-generation flow or audit, that engineers actually reach for weekly.

* A QA squad that feels led : The QAs across teams can point to concrete ways their work, tools, or standards improved because someone was finally driving it.

Requirements

Who You Are

AI-native, specifically for quality work.  You already use AI to generate tests, not just to autocomplete code. You've set up agentic tooling like Claude Code or MCP-based workflows so engineers can run on-demand test generation or code review against their own repos, and you keep experimenting with what AI can take off a team's plate next. This is unlikely to be a good fit if AI tools mostly make you nervous, or your use of them stops at your own personal productivity.

A strategic thinker, not a tool zealot.  Give you a team's current maturity level, and you'll design the testing approach that fits where they are, not the one you used at your last job. You resist the urge to mandate a specific framework or a specific coverage number before you understand the context. Someone who shows up insisting "we need to hit 90% coverage" or "everyone must use Playwright" without first learning how the team works will struggle here.

Deeply hands-on across the whole test pyramid.  You've built and maintained component, contract, API, E2E, and performance test suites yourself, not just reviewed slides about them. You're the person who steps in when the engineering team is blocked by the pipeline and can't ship. If your test automation experience stops at reading dashboards other people built, this role will feel out of reach fast.

A patient teacher who still ships.  Coaching engineers on testing practice and running enablement sessions is part of the job. So is personally building the CI pipelines and the tooling. You don't write the doc and hope someone else implements it…