A Project Management Playbook for Fintech Teams

Regulated work, on a board that didn't know it was regulated

Consider a fintech company's engineering team, around twenty people, building payment and account features under real regulatory obligations. Every release that touched money movement or customer data needed a documented compliance sign-off before it went out, not as a nice-to-have process step, but as an actual requirement the company had to be able to demonstrate if asked. That part wasn't optional and everyone understood it.

The board the engineers actually worked from, though, was a generic sprint tracker with no concept of a sign-off gate built in. Compliance review happened, in practice, as a message to the compliance lead asking them to look at a pull request or a feature before it shipped, and the "yes" usually came back as a reply in that same thread, or sometimes a verbal confirmation in a meeting.

That worked, in the sense that things did get reviewed. It did not produce anything that would hold up as a clean, demonstrable record months later, when someone needed to show exactly what was reviewed, by whom, and when.

Before: a sign-off trail scattered across threads, memories, and meeting notes

The specific problem showed up during audit preparation. Reconstructing which release had which sign-off meant searching chat history, cross-referencing pull request timestamps, and in more than one case, asking the compliance lead to recall from memory whether they'd actually reviewed a particular feature before it shipped. It was possible, but it was hours of reconstruction work for something that should have been a fact sitting on record already.

There was also a real risk that a release could ship without the review actually happening. A pull request merged and deployed didn't require compliance to have looked at it first, so the gate depended entirely on engineers remembering to ask, every time, with no system-level check that would stop a release from going out if that step got skipped in a busy week.

And engineers found the ad hoc version genuinely frustrating in its own right: pinging compliance directly, waiting an unpredictable amount of time for a reply, with no visibility into whether the request had even been seen. It felt like a bottleneck because it was one, just an invisible one with no queue anyone could look at.

After: an audit prep exercise that became a lookup, not a reconstruction

The regulatory obligation didn't change, and it shouldn't have: every release touching money movement or customer data still needed real, substantive compliance review before shipping. What changed was where the evidence of that review lived. A wiki page with page history, attached to the card that carried the actual code change, replaced a scattered trail across chat threads and someone's memory of a meeting.

It's worth being honest about the limits here too. A WIP-limited column doesn't know the difference between a fully-reviewed release and one that hasn't been touched yet, it just won't let a new one in while the column is full, so the team still had to size that limit carefully and treat it as a hard stop, not a substitute for compliance actually doing the review. What it removed was the chance of a release slipping through because nobody happened to ask.