When my co-founder Bernie Tschirren and I began to build the Rome2rio product, we drew heavily on our experience working at Microsoft in Redmond, Washington.
NB: This is a viewpoint by Michael Cameron, co-founder of Rome2rio.
As time passes and our team grows, we are consciously blending various cultural characteristics of US tech companies with our own Australian approach to work.... Here are a few of the things of which we are proud.
Hiring: Keep the interview loop short
The key to a great engineering team is hiring the right people, so naturally we put plenty of effort into recruiting.
We use the same style of interview loop process that Microsoft, Google, and other US tech companies employ, involving five or six hour-long technical and coding white-board sessions....
We also like to move candidates quickly through the entire interview and hiring process. Paul English, the CTO for Kayak, wrote that in the early days they had a seven-day rule for hiring.
We are not quite that fast, but certainly faster than most Melbourne companies. Typically it takes us two weeks from receiving a CV or referral to making an offer – it’s good to instill a fast-moving and decisive culture.
Workspace: keep it close and fun
The entire Rome2rio team, except for our global content staffers, sit within a few metres of each other. With so many complex engineering discussions happening every day, this arrangement is key to keeping development running smoothly and productively.
Bernie and I have both witnessed the communication and political challenges associated with distributed and remote engineering teams. Keeping everyone together is a luxury that larger companies often cannot afford....
Meetings: Keep them to a minimum
Engineers typically hate having too many formal meetings that get in the way of being productive, so we are pretty passionate about keeping meetings to a minimum.
We hold a company all-hands meeting once per fortnight where we present new features, report on conferences, share management news and learn from experiment results. We strive to keep the meeting under one hour; anything more and the team gets restless.
We run a 10:30 am daily stand-up for the engineering team at the office pool table. Each person gives a quick summary of what they accomplished yesterday, and what they’re working on today. In theory, it’s 60-seconds each (but, of course, it often goes overtime).
Ship it: Less talk more action
At Microsoft, whenever somebody demonstrated a cool new feature it was customary to yell “Ship it!”. It’s usually a joke (the demo is often pretty rough around the edges) but also demonstrates a culture of bias towards action that we love, and have adopted.
This culture includes doing regular releases to production (typically weekly) and minimising the amount of process surrounding making stuff happen. We don’t employ project managers and entrust engineers to drive a feature from concept to completion.
#TechDebtFriday
We introduced a new concept this year: Technical Debt Friday. The engineering team loves it; it gives them a chance to pause their regular development work and pay off any technical debt in the code base.
What is technical debt? As any code base grows there is an increasing amount of badly organised, poorly named, confusingly arranged, or no longer used functionality that should be cleaned up.
The debt builds up and is increasingly costly – adding more code becomes harder, more error-prone, and it takes longer for new hires to understand what everything does.
So TechDebtFriday is a tradition where we allocate each Friday to cleaning up the code base.
Perhaps tool X now actually does Y and Z but was never renamed. Perhaps class A represented two things; B and C, but, was never separated into two classes. Perhaps the load time of the product on our development machines has grown from 30 seconds to 60 seconds, but could be reduced again with some simple optimisations.
Basically, anything that makes our life easier, but has no immediate gain to our end-users.
It is interesting to note that a few years ago engineers at Booking.com complained that paying off technical debt is frowned upon by management. We believe it has real value.
Staff reviews
Software engineers often groan at the thought of a performance review. Some of our team have had bad experiences with them in the past, and they can be rather meaningless if done badly.
However, we believe they are essential for any business that wants to celebrate accomplishments and reward hard work.
Perhaps the only thing worse than performance reviews is not having them at all. This can lead to a culture where promotions are only given out to those that ask for them, or those that are threatening to leave.
We have been doing staff reviews regularly since we hired our first developer.... It’s a chance to reassess salaries, with the philosophy of promoting people based upon already demonstrated growth rather than promoting with the expectation of new responsibilities.
Beware the gender imbalance
OK, we’ve covered all the positive things so here is something we are not proud of – our engineering team is currently entirely male. We hope this is something we can improve with time, but fewer than 5% of applicants for engineering positions that we have advertised were women.
We have done better with the non-engineering part of our team, with 40% female representation. It is good to see the Australian Government investing to address this imbalance in the tech sector generally.
In summary
Many of the ideas described here are not new, and we borrowed many of from our experience at Microsoft. Hopefully, they give an idea of the type of culture we are striving for within our engineering team here at Rome2rio.
NB: This is a condensed version of a blog post from Rome2rio by Michael Cameron. While every company has a story to tell (and many of them are great), this one struck us offering some clear lessons in an especially conversational way that we thought might resonate with some readers.
NB2: Image courtesy of Rome2rio