Reblogged from Medium

Just half a year ago, I was interviewing for the role of front end developer at ReferralCandy. My primary concern then- like many other candidates- was the startup’s engineering culture and its effect on me.

Since then I’ve done great work that I’m incredibly proud of- like deploying a complete redesign of the product’s home page- and continue to be motivated to be more productive everyday. Here’s how I think ReferralCandy has optimised their development culture.

  1. We work in sprints and consciously block that time

Paul Graham was right– there is a difference between the maker and the manager’s schedule. That’s why we break work up into two-week sprints that start and end on Tuesday (Tuesday: because why would you deploy on Friday??). This shields programmers from interruptions, and gives us a chance to rest and reset at a predictable cadence.

Recently we’ve started experimenting with pushing our meetings to the start and the end of the day so that they don’t interrupt coding. One 4-hour coding session is more productive than four 1-hour sessions.

  1. We use Trello to keep teams organised

Our kanban of choice is Trello, which we use to coordinate within and between teams.


For each sprint, other teams can join the engineers in proposing things to be worked on by creating Trello cards. The engineers set out what needs to be done for each card, estimate the time taken and then assign ownership of each card to an engineer.

The engineer is free to decide how he wants to approach the task, at what times and even whether off-site or in office. To make this work, we have a brisk Stand-up meeting (via Google Hangouts) at noon every day to update each other on our progress and to ask for help or bring up blockers.

Screen Shot 2016-11-15 at 12.02.22 PM.png


  1. We use reviews, testing, and reporting to facilitate continuous deployment

Every merge into master is reviewed by another engineer via Github Pull Requests. Anyone is encouraged to leave feedback or even a motivational :+1:.

Git commit messages follow these guidelines

It is our integration with TravisCI and extensive testing and linting with Rspec/Rubocop (for Ruby on Rails) and Ava/Standard (for React/JS) that gives us this confidence to deploy. Continuous deployment is awesome- our customers get the fixes and features they want faster, and we get more frequent kicks from seeing our code in production.

Despite these measures, I once broke a feature for lots of retailers. Our error reporting via Rollbar and Errorception caught it and raised an alert in HipChat, our team messaging service of choice. Because our development machines are hosted on AWS, I was able to deploy a fix remotely even before complaints were raised to our Customer Success team. It’s an incredibly smooth and enjoyable development process.

Like any good startup, we’re moving fast, experimenting, learning from failures and optimising for a better experience. If you’re an engineer, we’d love to hear about better ways to do these things. And we’re always looking for great engineers- check out our job openings at or just drop Zach (our cofounder and head of product) a message at