How We Build Product At Bench.

Photo by Hello I’m Nik 🎞 on Unsplash

A New Process

Like so many Engineering organizations, Bench Engineering was a two-week-sprint scrum shop. As its leader, I knew that our implementation of scrum was sub-optimal, but I couldn’t figure out what exactly was wrong, or what alternatives existed.

Then, through a combination of luck and curiosity (I had 4 hours to kill while sitting on the floor of the Munich Airport trying to get home during the start of COVID), I read Basecamp’s book, Shape Up (see important update re: Shape Up’s author at the bottom of the article). It hit me like a lightning bolt. It immediately articulated my dissatisfactions: too many distractions, easy-to-flex timelines, and a culture of “ticket takers” over creative contributors.

As soon as I read it, I knew that we needed to change.

We began the shift in March, and now — 11 months later, we’re starting to get pretty good at it.

This post is about how it works, the benefits, the gotchas, and the results of our change in process.

How It Works

Every eight weeks we hold a “betting table” where we review pitches created by folks across Bench. Right now, these are mostly from our Product team, but we’re seeing more and more pitches from other departments. The pitches describe a problem to solve, the payoff from solving it, and how we can measure our success along the way. They crucially do not prescribe a solution — just the area to focus on.

At the betting table, key stakeholders choose the pitches that are most suitable right now for our overall strategy, as defined in our quarterly OKRs. We then pull from our talent pool — a group of engineers and designers-who-code — to create teams around these projects.

A few days later, it’s off to the races.

Teams get six uninterrupted weeks to plan, design, and build. We measure success not in deliverables, but in value created for our clients: the payoffs described in the pitches.

During the build cycle, we have a weekly cross-team meeting of technical leaders to ensure we’re on track for success and, if necessary, update our commitments. Other than that, teams meet as often or as rarely as they need. Think of it like a six-week hackathon, with no overtime allowed.

After the six weeks are up, we do a two-week “cooldown” period so our build teams can handle things like small refactors, hardening up tests, and cleaning up UIs. It’s a bit like a restaurant cleaning up the kitchen between meals — we need to be ready for the next rush.

The Benefits

1. Our time is our most precious resource. We no longer ask: “how long is this going to take?”. We ask: “how much time do I want to spend on this problem?”. This gives us control over our timelines, and empowers us to collaborate more effectively with the rest of Bench, and create value for our clients at speed.
2. We can now say with certainty that the work that we’re doing in Engineering is always aligned with Bench’s strategy. Before this, we planned quarterly, which could never keep up with changes in strategy.
3. Focus! Our build teams get to arrange themselves around a goal, and go heads-down. Yes, there are exceptions for things like interviews, but in general, our build teams report that they are significantly less distracted than they were in our previous system.

The Gotchas

1. Shape Up suggests that bugs can be left for cooldown. That didn’t work for us. We’ve created another team to maintain and improve our in-house software and its infrastructure (we call it “Core”).
2. Change management is hard. We made this significant change during the COVID-19 pandemic, which made change management harder. If you do something similar, expect that some folks aren’t going to be happy with the change. It’s up to the leaders to ensure that these folks are heard, and that they start to see the benefits of this change. If they don’t (and some won’t), you need to unearth that dissatisfaction as quickly as possible.

We definitely acted too slowly, and some of the conversations on our teams got pretty ugly. We’re over the hump now, but we made it harder than it needed to be by taking too long to engage with the dissatisfaction on our teams.

The Results

The speed with which we’re getting technology in the hands of our clients is unrecognizable from where we were at this time last year.

Because we work with fixed blocks of time, it’s much easier for us to collaborate with other departments across Bench. These fixed cycles also give us a regular cadence for process iteration, so we can continually improve the way we work each cycle.

This is huge for us, and it has created a new level of confidence in our ability to create the future we’re committed to.

Written by Blake Turner, Head of Engineering at Bench.

—

Want to learn more about Technology at Bench?

• We Built A Tool To Help Us Foster Growth In Our Engineers
• Breaking Good — Having A Blameless Engineering Culture
• Three Unexpected Benefits of Career Development Tracks in Engineering
• Measuring Agility
• Don’t Optimize For Tenure

If you are interested in learning more about Bench Accounting or a career with our Engineering team, apply here: https://bench.co/careers/

*Update: May 7th 2021. Through following the serious cultural unrest at Basecamp, we learned that the author of Shape Up, Ryan Singer, upholds values that are wholly inconsistent with Bench’s stand for Diversity, Equity and Inclusion. Specifically, he denied the existence of white supremacy in an all-hands meeting. We now find ourselves in a difficult place where we have adopted the ideas from a book written by someone who we cannot support personally. The exercise now is to get very clear about which ideas matter to us from this book, and use them to create our own manual, unique to us. Through this we must also be critical about the systems the book suggests, and be mindful that they may be influenced by the biases of the author. Once the dust has settled, we will create a new post about our own build process.