Prior to launching Zendesk in 2007, I was working as a consultant for some of the larger organisations in Denmark. My role would typically be to come in and make progress in areas where the customer had stalled due to a lack of in-house expertise or just plain inertia.
The age, size and culture of these companies often meant that technology was considered an isolated tool rather than integral to the business, and the result was a very predictable (i.e., slow) pace of progress. At Zendesk, it’s the complete opposite.
Speaking as a CTO, one of the things I’ve most appreciated about our journey is how much opportunity the business has provided the engineering team and vice versa. Since the very early days, we’ve been full steam ahead, forging our own path as we progressed. In many ways, our story is about pulling the right levers at approximately the right time, such that engineering could keep building a platform of opportunity for the business.
To pay it forward, we want to share what worked for us to help inspire new startups to identify the levers available to them and think about the right ways to use them.
Go with what you know
When we moved to the U.S. in 2009, we had little understanding of how things actually worked outside Europe, but that’s just the reality of most startups — you’re operating on unsteady ground and encounter new unknowns every day as you push forward.
While still getting our bearings, we started hiring the local team that would be the core of Zendesk engineering for a long time to come. Over the next couple of years, VCs in the Bay Area were getting increasingly optimistic about technology again, after the slump of the years prior. One of the challenges of the more optimistic climate and the thriving tech sector was that it became incredibly hard to find great engineers to join our team, it was a competitive environment.
We had some previous experience with outsourcing, but that option required an organisational commitment of a kind that was not in our DNA, and our first-hand experiences had frankly not ended particularly well. We decided to go with what we knew, and that took us back home, to Denmark. We figured that our Danish heritage, network and brand would give us a significant advantage in the Danish startup and technology communities, and we decided to put that hypothesis to the test. A few months later, in 2011, we had our first remote engineering team operating out of Copenhagen.
What I learn from that experience was navigating the unknowns of a startup can easily take up all your time and then some, which makes it particularly important to reflect on your current position and go with what you know to gain an edge and push forward.
Guide, don’t collide
Getting the Copenhagen team up to speed taught us a lot about ourselves, our assumptions, and, not least, what it takes to make a remote office work well. Unsurprisingly, it’s all about the people, but it’s also very much about how you set them up for success.
A new team needs enough guidance to not feel like they’re constantly struggling to justify their own existence, but at the same time, the business needs them to have enough autonomy to become masters of their own destiny and success. It’s only when we have creative freedom and a strong vision and drive that we really get excited about our work. Getting a team to that point is a priority for any healthy organisation.
The first time you build a new team halfway around the world, there’s going to be some turbulence as people settle in and figure out how to handle communication, the division of labor, and all the odds and ends that are part of it. Sometimes this can lead to overlaps or double ups where, for example, one team starts working on the same piece of code as another and collisions occur.
This period of scrambling can take quite a while, and it’s taxing on everyone so it’s important that the initial hires in a remote office are flexible and creative solution providers. At the same time, they need to be tolerant of the chaotic nature of a startup and find ways to have a good time while finding their feet.
For engineering specifically, there are a few particular challenges in working on the same code base: It’s really hard to translate the history of a piece of software to a new member, much less to someone who’s working on another continent. This realisation is what eventually drives you to (re)discover Conway’s law and end up giving the new team a mission of their own (Conway’s law states that the structure of the software an organisation builds will follow the structure of the organisation). This can be an opportunity to shield the remote team from the legacy product (as we did) and get everyone to agree on a set few interfaces and key interaction points. But outside that, empower them to evolve a vision or a product and run with that.
As the engineering team continued to fan out across the globe, this rule of providing autonomy with guidance has enabled us to minimise potential areas of collision and instil a culture of creativity, innovation and, to a certain extent, freedom.
Listen to the business
There really is a time for everything, and getting the timing right in a startup is crucial to its success. When you have zero customers and zero funding, it can get very, very hard to stay motivated and focused. At that very early stage, your job is to build something just slightly usable that you can ship to see if people would even consider using it, rather than polish a feature in secrecy to the detriment of your chances of success.
As you manage to land those few very important first customers, it’s crucial for you to make it easy for them to tell you what they need, and give it to them. Early on in a software product, you can change the world in days, if not hours, and this is where your product vision will be tested and forged as you iterate quickly and take the product in the direction the business leads it.
As you get funding, the pace naturally picks up because of the investments you’re now able to make in the product and the business. You will be busier than ever keeping up and feeding the machine, and at this time it’s important to remember to pull yourself out of the trenches and pay attention to the world around you.
When you’re sitting on a rocket, the world can change so fast around you that the plans you made yesterday are no longer relevant. So while it’s tempting to mentally focus on the problem of the day, it’s important to put things at arm’s length and use that distance to get a new perspective on whether yesterday’s problem is still the most important thing you should be working on today.
In a fast growing company, there will always be odds and ends that only a few people know about, and the migration from betting your startup on a few bright minds to organisational ownership is a long but inevitable journey.
Listening to the business means different things at different times of a company life cycle. Very early on it means to be in the grind and help get traction wherever you can; later it’s about feeding the machine while you help the organisation get in place and stabilise.
Over the years, we’ve evolved our engineering organisation to become truly global with departments in Copenhagen, Dublin, Madison, Melbourne, San Francisco and Singapore. We’ve applied the same few core principles in all these offices, and have found the model to contribute tremendously well to our success in recruiting the best people on the planet and making them successful.
We have fully embraced being a global engineering organisation, and while it does come with a set of challenges, we find that we can overcome lots of those using communication, spending time face to face, having great people and leadership in place, and not least, investing in preserving our company culture in each and every office.
The challenges that do come with multiple distributed teams are real, and they force us to think about how our organisation and lines of communication should look just a few months from now and well beyond.
What next?
Some people think that when you’ve built a billion dollar business you’ve made it. One thing that I’ve learnt is that you keep on learning. Every day presents a new challenge and new opportunities. I’m developing skills all the time that I never knew I had or thought I’d need. Key to it all is to have the right people around you and to make sure they enjoy what they do as much as you do. Have a good culture and let people do what they’re good at—what you hired them for.
