Scaling On-Call: from 10 Ops to 100 Devs

This is an Ignite I gave at DevOpsDays Sydney 2016.


Like a lot of on-call systems ours was once pretty terrible. We had 10 operations staff on-call, and we were responsible for every system in the company. Spending a week on-call usually meant a week without sleep.

A sleep deprived first responder waking up late at night to a buzzing phone and a laptop screen burning bright with nagios alerts

Eventually one of the on-call engineers got fed up with this, so they removed every single check from the after-hours notification period. They then went through and selected only the most critical ones to put back in. Continue reading

Getting to Gender Parity without the awks

On the 30th of November I spoke at CTO Summit about Getting to Gender parity without the Awks.

Previous attempts I had made to sum up answers to ‘How can we attract, retain and inspire more women in technology careers?’ had left me fumbling for easy-to-digest responses. My male colleagues wanted to help, but it can be an awkward conundrum to untangle and confront.

On one hand I’m sure I’ve been the recipient of some positive discrimination in my career: was I entitled to weigh in on this subject? Continue reading

React Training is Coming to Melbourne

We have been busily re-building our core property listings experience using ReactJS for a while now. After the release of our revamped sold property section, we decided to find a way to engage the other areas of the company and give back to the local tech community.

With that in mind, REA Group is very excited to announce that on the 8th – 10th February 2017 we will be hosting a ReactJS workshop run by the amazing React Training team. React Training is a US based group comprised of ReactJS experts and the creators of some of the most popular open source libraries in the space, many of which we use here.

REA and React Training

Continue reading

What it means to be a QA at REA

A few of our wonderful QAs at REA Group

When I first joined REA, I soon realised that the QA role at REA is very different from a typical QA role and the roles that I had done previously in my career.

Some of the highlights of being a QA at REA for me are:

  • The entire team owns the quality of the work we do. You are not the Quality Gatekeepers
  • QA at REA is not defined as Quality Assurance but Quality Analyst
  • You are free to venture into previously unknown territory like BA or Ops and it is encouraged
  • You are not meant to test every card that gets developed
  • Your role is not limited to the testing column on the Kanban board
  • If you are passionate about the work, you have a voice in determining what work you actually do
  • Your efficiency is not measured or based on the number of test cases you create/execute
  • You are trusted with access to most critical production systems, so you can learn and contribute more
  • You are not meant to document each and every test case you execute
  • You can get help in finding bugs. E.g. Bug bashes
  • You can pair with developers on testing
  • QA effectiveness is not measured based on the numbers of bugs that you discover
  • You can do pretty much anything on Hack Days, be it on a project or your personal project to improve your automation skills
  • You can attend a countless number of external training or conferences
  • You have a vast array of internal training available, including technologies like AWS and Docker.
  • You can be part of the QA Guild where you can bounce ideas off other QAs in the building and share ways of working
  • You can get an REA T-shirt just for QAs!

While the role came with a lot of benefits there were some challenges too. Understanding what other QAs at REA do was not easy. This made it hard to learn from each other.

To help increase visibility I decided to come up with a QA Strategy initiative which first will enable us to talk about and understand what QAs at REA really do, and then help us come up with strategies to improve. Continue reading