Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

A while back Atlassian reached $100 million in all time revenue. We’ve asked some of our employees to give us their take on how they’ve seen the company grow. Better late than never, VP of Engineering, Soren Harner:
When I joined Atlassian in 2007, we had one-third the number of people in product development we have today, crammed into two rooms in a small office on George St. in the Sydney CBD. Bicycles were parked in all corners, and there were no showers, which made pair programming a challenge in the summer. All but two people wrote code, including the occasional juicy titbit from co-CEOs Mike and Scott. JIRA and Confluence had half the customers they have today. Crowd and Bamboo were under construction but not released into the wild.
Atlassian had the feel of a startup. Developers were generalists. Each could code features top to bottom, from the UI, through a handful of open source frameworks, to the database. Developers also did support, documentation, testing, system administration, product requirements and even marketing. They felt connected to the whole business. The organisation was flat. Yet early employees felt the place had become huge. The decision to create my role was controversial. As a development manager, I was one of the early Specialists.
Yet we were just getting started. The challenge then was the same as it is now: Deliver on ambitious roadmaps while inching up quality. JIRA and Confluence had just come off gruelling releases, and those teams were struggling to keep up the impressive leaps in functionality of earlier releases. I focused on ramping up hiring and scaling up the organisation to support more people efficiently. The goal was to have the structure, roles, infrastructure and processes that could sustain to several hundred people, if needed, without sacrificing innovation.
We practice peer-based hiring, where developers rather than managers make the hiring decisions. When interviewing a new developer, the single most important question is, “Would I want that person on my team?” In additional to the team in Sydney, we brought on a team in Poland and added people in San Francisco. We acquired Cenqua, adding Clover, Crucible and Fisheye to the portfolio. We found a new home on Sussex St with indoor bicycle parking and showers.
This growth has accelerated the shift from generalist to specialist. To name a few, we’ve added front-end developers to craft clean and cross-browser CSS and Javascript. The Design team creates mock-ups, UI components and does usability testing. Technical writers handle the documentation. We now have more development managers who don’t code. We have a QA team. Performance engineering has created baseline tests for load and stress. Programme management serves as air traffic control around complex dependencies of product integration. We also ramped up other departments: Product managers consolidate product requirements; as the Support Diva describes, support engineers have become skilled at solving problems that once passed through to developers.
To those of you at 100+ person companies, these roles seem obvious enough. Beyond some inflection point in scale and complexity, a team of specialists can achieve more throughput, more consistency and higher quality. Yet if you’re a generalist nearing the threshold, this is a time of torment. Specialisation puts generalists in boxes, where they have less freedom and perspective on the whole business. It slows you down before it speeds you up. Specialists need more structure and are less versatile than talented generalists. You owe your success to the generalist’s determination and resourcefulness. There is a real risk that it will impact innovation. Some great apps come from small teams that consciously stay small decide not to cross that line.
Although we sometimes refused to admit it, we had crossed the line to become a medium-sized software organisation. Soon we had seven products, and we were integrating them into a new product, JIRA Studio. We desperately needed to take the plunge. Yet the transition was full of risks. Early on, I created a “don’t change” list of the good stuff we didn’t want to break, around innovation, open communication and practices found in the values. Also since software developers are a sceptical bunch, each new specialist would need to win over a tough crowd.
We worked hard to find people who would question how their past experience would apply here. Each would need to hand craft their role to our needs and build the trust of the team. To name just a few, Melanie Carasso has evolved an Atlassian form of programme management. In addition to being a skilled writer, Sarah Maddox promotes wikis in the technical writing community. Don Brown created the Integration Architecture role for himself in response to the challenges he saw first hand trying to integrate products to create JIRA Studio. Andrew Prentice has introduced testing practices that maximize the benefit of a small QA team to complement the automated tests that developers write.
It has been a cautious, incremental approach to expansion, and it is still evolving. The generalists are focused on the parts of the job for which they have the most passion. Specialists have innovated in their roles and often present those innovations at conferences. I’m incredibly proud of what the teams have been able to accomplish, and I look forward to kick ass product releases that will bring the next $100 Million.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now