This is part two in a series of posts about how we're growing as a company. In this post I'll talk about how we collaborate as a team.
- Developer career paths
- How we work
- Compensation and career progression
- Interview process
- Laptop program
- Anti-harassment policy
- Local or remote?
Where we work
When Octopus was just me, I worked from home. As we grew, we continued to work from home, chatting online or over the phone. Developing software requires collaboration, so since we were in the same city, we started to meet up on a regular basis in public places like cafés and libraries. For about a year, our regular meeting place was the Queensland State Library. Meeting once a week in person was a great way to have conversations that were harder to have online.
At first we just worked from the state library café, but as we grew to five or six people finding a café table (and power) became exponentially harder. We started to book meeting rooms at the library, but they were sometimes hard to get, and had a 4 hour per-day limit which meant we'd have to go home after lunch.
As a team we decided that continuing to meet in person was important, but the library and public spaces weren't working. We had also tried the iLab, who were kind enough to give us some desk space, but since we weren't using it each day we felt like we were imposing on other people's space - at least public space belongs to everyone. So we decided to get an office.
It took a few months to find the right place, but we eventually settled at 4/540 Queen Street. It's now turned into - in my opinion - a great little place to work:
We treat the office similar to how we used the library: it's a place to come when we need to collaborate, even if we still predominantly work from home. We meet as a team every Wednesday (more on that below), and then we might come in on Friday for interviews, or on Tuesday to do some pair programming/designing for an upcoming feature. The office is a place to use if you need to use it. If you don't, avoid the traffic and stay home. On days when I do find myself in peak hour traffic, I'm reminded just how much more time I gain with my family most days of the week.
We hire professionals, so we trust them to work and manage their time, and judge based on contribution rather than on time spent at desks. We do a daily standup each day around 9:30AM via Google Hangouts (or in person if in the office). Aside from that, there are no core hours or key times, and we trust people to work whichever way suits them.
Aside from the morning hangout (and support calls, which I'll discuss in a future post), we communicate pretty asynchronously throughout the day using Slack. One thing I'm proud of is that we use email extremely rarely internally (customer communication involves a lot of email, unfortunately). If you need to talk to a team member, either chat on Slack, ask them to jump on Hangouts (a permanent Hangout is always ready to use), or Skype the person you're trying to reach. It's rare to check your email in the morning and see an email from a team member.
Every Wednesday is our meet up face to face day, when we all come to the office. What we do that day will vary, but having a fixed day works well since you can plan for it and save questions/conversations for that day.
We do two week sprints involving the whole company, which end and start every second Wednesday. Sprint start/end Wednesday typically looks like this:
- Sprint review: everyone does a short presentation on what they've been up to during the sprint. Developers working on a feature together might do a demo. Vanessa does a presentation summarising the key support tickets and trends. We cover hiring decisions, office improvements, marketing activities - basically anything that we did over the previous two weeks. It's great to see people share what they've been up to, and it's the highlight of my fortnight.
- Retrospective: what worked? What didn't work? What can we try differently this week?
- Sprint plan: what are we going to do this sprint?
We use GitHub issues to track what we're working on, using a public issue repository for public things, as well as a private one. Huboard gives us a task board view over both issue lists combined. Since we have "One Sprint", this means that the backlog contains a mix of tasks: development, operations, marketing, support, documentation, office renovation work; anything anyone is spending time on this week. We discuss what's involved with any items in the sprint, and we decide whether some items need any research or a short spec/RFC written to help figure out how it will be implemented.
On the "off-Wednesday" (in the middle of a sprint) we use the day to pair up, discuss features, or to do a bug bash or documentation bash. If you haven't tried a bug bash, they are great fun and have been the single best way we've found of finding issues that can't be discovered via TDD (and are way better than a dedicated tester).
As far as process goes, that's about it. Daily standups via Hangouts, weekly meetups in person, work from home or in the office - it's up to you. Sounds like a place you'd like to work? We're hiring!
Octopus Deploy is used by thousands of developers across the globe, from small companies to large enterprises. Find out if it meets your deployment automation needs by taking advantage of our free 30-day trial. You can spin up an instance with just a few clicks!