When engineers ask what it’s like building at Finch, I tell them the best part is also the most challenging — engineers own outcomes.

Right now, we don’t run a traditional PM loop. Engineers build for their coworkers in the room — the paralegals and case managers moving hundreds of personal injury cases forward daily.

We collect written feedback and track issues like most shops — but our velocity comes from  open access to our colleagues: we build together from what we observe, not only what we’re told.

A more expansive toolkit

Owning the outcome has led to interesting working modalities for engineers:

• Process as product. If a small SOP change unlocks big automation, we pitch it. Example: having a human responsible for confirming the defendant’s name at intake gives us a major edge at extracting insurance coverage later, and might incur nontrivial work for our operators.
• Pragmatic hiring budget. When it unblocks the outcome, engineers can bring in short-term help — e.g., data-entry contractors to templatize cover sheets or map phone trees.
• Engineers can trial vendors at will, and make an evidence-based call to buy vs. build.

The other edge

Owning the outcome also means owning uncertainty. There’s a moment in every project where your progress depends on something you can’t just ship: adoption, alignment, patience.

A goal being achievable can hinge on whether operators adopt a shared inbox, thrash into a new tool nobody loves, or re-confirm information. Those are small asks that feel enormous in practice.

It’s moments like those where earned trust and latitude with your operators counts for everything.

Example: Records Requests

Early on at Finch, we planned a build to provide automation leverage for records requests. The core elements of a system were laid out: document composition, transmission via fax/email/mail/online portal, and lifecycle tracking.

A reduced summary of that systemized lifecycle of a records request is an async job, where we poll for status until the records come back from the facility. In any other shop, I feel like our requirement gathering would have stopped there.

Working with paralegals up close, timely retrieval of records was less about our speed of transmission, and more about follow-up calls post-transmission, which were happening constantly.

A check-in call with a record-holding facility reliably de-risked compliance issues, and improved turnaround time — it was revealed a follow-up wasn’t an edge case, it was part the lifecycle.

The system analogy here would be that polling for status reduced the latency of an async job.

We encoded that behavior instead of pretending to replace it: timers that age requests, re-contact cadences, last-touch tracking, gentle escalations. The lesson wasn’t “more automation”; it was own the lag, not just the send.

What it means to build here

The goal isn’t just to automate — it’s to make the invisible parts of legal work visible, repeatable, and improvable. Every feature ships with a shadow component: the workflow it enables or replaces. Owning outcomes means we hold both in our hands at once.

That’s the difference between software that fits the work and software that changes the work. The first is efficient; the second is transformative.

When engineers see their tools used at the next desk over, every decision suddenly feels closer to the ground. You stop asking “what should I build?” and start asking “what’s actually happening?”

That’s the loop we live in — one foot in code, one foot in the workflow. And when it clicks, it’s the most rewarding kind of engineering there is.