How we build software: Small teams, thoughtfulness, and why our CTO still codes
We modified Shape Up, built Griffin's Den to keep us aligned, and designed an engineering management style that works for us.
Photo by Growtika on Unsplash
Most engineering organisations follow a fairly standard playbook: agile sprints, teams of 8-10 engineers, managers who've long since stopped writing code. We don't do any of that.
Not because we want to be contrarian for the sake of it, but because we have learned the hard way what works best for us over a long period of time. Our co-founder and CTO Allen Rohner, VP of Engineering James Trunk, and CEO David Jarvis recently sat down to talk about how we actually build software at Griffin: the messy, opinionated bits that don't usually make it into polished engineering blog posts.
Why we killed vanilla Shape Up
We started with Shape Up about four years ago because it elevated something most processes ignore: the importance of properly shaping work before you start building. But we quickly realised the book version didn't work for us.
The biggest change? Griffin's Den. Shape Up assumes you'll come to planning with 3-5 fully shaped ideas ready to go. That's almost impossible when you're building financial products. Discovery takes time (sometimes a month or two) and you can't rush it. Rushing it means you'll likely end up with technical and regulatory debt, and that's not a position we want to be in. So instead, product leads spend a week on 3-5 ideas, pitch them at Griffin's Den, and then the winner gets properly shaped.
Griffin's Den serves another critical function: it synchronises the entire organisation. This is especially important at a bank where product decisions have downstream impacts on banking ops and treasury. When you have multiple teams working in parallel, it's easy for priorities to drift. Griffin's Den forces us to explicitly decide: A, then B, then C. Everyone knows what we're building and why.
Engineers drive the how, product drives the why
About a year ago, we also made a significant change to how product and engineering work together. Product leads used to get too deep into solution design. We've completely taken that out of their hands.
Now Product is responsible for over-investing in why. Why are we building this? Why now? Why this customer segment? Engineers own the how. They drive shaping, they decide the architecture, they determine which part of the codebase gets modified.
We didn't just move stuff around. This change was deliberately designed to make our engineers happier and more invested—they are not being ‘told’ what to build and how to build it. It also made our product leads stronger because they now spend more of their time talking to customers and interfacing with our commercial function rather than trying to engineer solutions.
Small teams, high context
Our engineering teams are typically 3 people. Industry standard is 8-10. This sounds insane until you realise what it enables: focus, ownership, and massively reduced coordination overhead.
Small teams can't over multitask. When you only have three engineers, you tend not to farm out work across 10 concurrent threads. You pick the most important thing and you do it until it's done. That focus is powerful.
But small teams only work if your managers stay close to the code. This is Allen's most controversial belief: the CTO should still be good at writing code, not just have been good at it once. We also expect all our engineering managers to contribute technically. It's the only way they can properly evaluate their teams, make hiring decisions, and maintain the context needed to make good calls.
We're hiring
We're looking for engineers with Clojure experience or those willing to learn it. If you have functional programming experience and want to work on genuinely hard problems in banking infrastructure without cutting corners on quality or compliance, we'd love to hear from you.
Check out our open roles at https://griffin.com/careers.