Atlassian's Dom Price on scaling team culture

But as a startup grows, hires more people, builds more products and adds more customers, teams and the way they work get infinitely more complex. So how do you grow your teams while maintaining this early-stage way of working?

Ask Dom Price, head of R&D and work futurist at Atlassian, and he’ll tell you there’s no silver bullet to this problem, but there is a series of methods that can set you up for success. Dom’s helped Atlassian grow from 400 employees to north of 2,500 and six global offices. Today he travels around the world analyzing how Atlassian teams work and visiting with outside teams across industries to share insights.

Dom joined me on our podcast to chat about the importance of cognitive diversity in high performing teams, maintaining a culture of innovation at scale, how to check the health of our teams, and much more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed in your player of choice. Below is a lightly edited transcript of the conversation.

Adam Risman: Dom, welcome to the show. You’ve had an interesting career trajectory ranging from consulting with Deloitte, working in the casino gaming industry, and now you’re in collaboration software. How did you get where you are today?

Dom Price: I’m a recovering accountant. I was convinced by my parents and various family members when I was finishing university that if I wanted to have a job for life, I should go and become an accountant. What I really liked early about accounting is the nuances of business – how everything kind of connects together. I was fascinated by how businesses actually work.

My casino gaming time was around building slot machines around the world, which was fascinating, and then I took that knowledge of building games en masse to Atlassian, where I got to see a company scale from tiny to large in a very short period of time.

Adam: Today you are the head of R&D and work futurist at Atlassian? What exactly does that role entail?

Dom: It entails having the most random title in the world, but it’s fascinating. It’s a role I’ve not seen anywhere else, which is why I’m enjoying it so much. Half of it is internally focused in Atlassian. How do we scale our teams? How do we stay awesome? How do we find better ways of working as we grow, as we get more people, more complexity, more customers and more products? We’ve got infinite amount of complexity in our business and we don’t want that to slow us down. We want to stay small, autonomous, nimble and empowered.

As we’re learning ways of doing that at Atlassian, the other half of my time is sharing how we do that and why. We don’t believe that knowledge is power; we believe the application of knowledge is power, so we’re giving away that knowledge for free. We want other teams to unleash their potential and find new ways of working. As I watch and observe and listen to the challenges they’re suffering, I document all that and I take that back to Atlassian, so we can evolve our ways of working. It’s a very tight, infinite loop. Companies that are large, small, new, old, startups, established, different industries – every team is subtly different. The themes tend to be similar in terms of what they’re challenged with, but I learn something new every single day, every single week.

From 400 to 2,500: scaling teamwork at Atlassian

Adam: Take me back to when you joined Atlassian. You were around 400 employees, had just acquired HipChat and were two offices then.

Dom: It was fascinating. I remember at the end of my first few weeks being genuinely confused as to why they’d hired me. I was literally walking around saying, “There’s nothing for me to do because everything works.” My previous roles had been at more traditional or established companies going through a high level of change where they’d realize there was an old way of doing things and they wanted to transition to a new way. That required a lot of firefighting.

At Atlassian, we didn’t have fires yet. Thankfully, my boss, the VP of engineering at the time, sat me down and said, “I want you to take all of the things you’ve learned in firefighting, reverse engineer what went wrong to create the fires, and prevent those fires from occurring here as we scale. You’ll get most of it wrong but the stuff you get right will be invaluable.”

I realized there was a huge amount of unlearning I had to do, because my habits that I brought with me weren’t going to make me successful at Atlassian. That took a lot of ego transition, which was difficult, but I managed it. Then I had to learn new ways of doing things, and about half of them failed, but that was cool because we were exploring and experimenting every time.

Adam: Now Atlassian is 2,500 people and you’ve got offices in the Netherlands, Japan, the Philippines, Sydney, San Francisco and Austin. What were the types of things that you had in those early days that you wanted to preserve as you scaled to this point?

We never want to be famous for being big.

Dom: That’s a great question. Fundamentally it’s the feeling of being autonomous and small, which sounds obvious. But as you scale, the things you hear are, “Oh, we’re a certain age now. The company’s 12 years old, we should grow up.” I don’t understand why the company at 12 years old needs to grow up. I’m 39, and I’ve not grown up yet.

It’s this idea of, “We’re a certain size, therefore we need a certain amount of structure and certain ways of doing things.” That’s where a lot of really successful companies become mediocre. They become run of the mill. It’s like the innovator’s dilemma. When they were small, they took calculated risks, then they became successful and had something to lose so they became conservative.

We were really nervous about that happening either on purpose or by accident. We said, “We never want to be famous for being big, but we want to be famous for being awesome. What does awesome look like, and how to we find ways of building that?” I did what all good people would do and went to the external literature, because I thought if someone’s done this already, I’ll quite happily copy, cut and paste it. I found a lot of old school management techniques around scaling a business that were nothing to do with what we were trying to achieve, and they weren’t focused on the people or the customer. They were focused on efficiency and scaling of business.

It was a little bit depressing. It was sell your mojo, lose all your passion and guile, and just get yourself comfortable. That wasn’t the Atlassian business, so we decided to go and create our own way, whether that be scaling offices, opening new locations, scaling our values and culture, or scaling our innovation rituals. Take ShipIt as an example of one of our innovation rituals. The first time we ran ShipIt there were 14 people in one location. We’re doing ShipIt 40 in a few weeks, and last ShipIt, ShipIt 39, we estimate 1,500 people took part in 400 teams.

Innovating through ShipIt days

Adam: For those that don’t know, talk to me about what ShipIt is.

Dom: ShipIt is a 24-hour ritual. All our team members across the globe get the same 24 hours, to stop working on their normal backlog or normal work, form a team, and go and work on whatever they want for 24 hours. It’s like a traditional hackathon on steroids, because it’s not just for tech teams. Probably a third of our teams that took part last time were non-tech. HR, finance, legal, marketing, it’s a whole myriad of people that still have great ideas.

You hack away for 24 hours, and the one rule is you get three minutes to pitch your idea at the end. Then there’s voting, and the prize is bragging rights. There’s no massive dollar prize or big check. You get a really tacky $3 trophy, and you get the plaudits of your peers. Often if you get recognized for a great idea, you then get the opportunity to follow through on it and see it in the wild, which is a great intrinsic motivator for our people.

That tradition has stayed with us now for years. We’ve had to scale the logistical side of it, but we’ve kept the spirit and philosophy very, very similar.

Adam: What are the types of things, both in terms of product and internal culture that have come out of ShipIt?

Dom: The internal culture ones are some of the most fascinating to me. They’re never going to make a headline in a big business journal, but they’re the ones that create incremental progress and drive real momentum in the business. A couple of ShipIts ago, a team of newbies from various different backgrounds – some international, some local, different functions and roles – joined together with a program manager and a designer to rebuild our 90-day onboarding plan.

They had all gone through 90-day onboarding recently, and they all agreed that whilst none of them hated it, there was much room for improvement. Having just been through it, they were the perfect people to change it. In a traditional organization, you’d give that project to HR, and in a vacuum somewhere a really smart person would create a plan that bore no resemblance to reality.

Atlassian’s 90-day employee onboarding is one of many non-technical projects tackled during ShipIt.

We took five people that had just gone through that who were not HR people, and they rebuilt it, tried it with a few people, and then they scaled it. That’s now our de facto standard. Wherever you join in the world, you’re going to go through a similar 90-day onboarding experience. One of them was into gamification, so their 90-day experience is very, very engaging in how you go through the first 30, second 30 and last 30 days.

It’s great to see that kind of stuff. When you’re growing at the size we are, you’re adding hundreds of people a quarter. Something like a bad onboarding experience can make a massive impact, and not in a good way. Getting that frictionless and engaging, building the passion, and getting people effective quickly, that’s a huge positive impact on the business.

One of the people on the team is a UX designer, and we had a product manager on the team. You wouldn’t associate them with building a human, 90-day onboarding plan, but they have to think about onboarding of customers to our products every single day. Taking that analogy of onboarding for a product to onboarding for a company, and building some kind of ethos from that is really valuable.

The transition from server to cloud

Adam: Another change in the earlier part of your time at Atlassian was the shift from a server-based business to more of a cloud-based business. Did that impact your work?

Dom: It’s an interesting transition that we’re going through. The customer is paramount to everything that we do, and one of the things we were realizing was we were getting an increased demand from our customers who wanted a cloud product. Our traditional on-premises product wasn’t going to work for them in terms of a deployment method.

At the time we were thinking about those customers as the same. It was only a small amount of research that our designers, product managers and execs did, and then we realized that someone who bought a cloud product was a different customer persona to someone would buy an on-premises product. They had different concerns, different worries, different priorities. Us delivering the same product but just packaged differently wasn’t actually serving them. It was serving us, but it certainly wasn’t putting them at the center of the solution.

A couple of years ago we decided to prioritize how could we understand that deployment method and their different needs. It’s not that we’ve transitioned from a server business to a cloud business; we’ve just said, “The way you consume our products is different, and we have to delight you.” A cloud customer may want features quicker, and the richness of integrations; our on-premises customers are often larger of scale, and are worried about compliance and high availability.

The priorities are different, and if we mesh those together, we’re going to make a really mediocre product. If we try and delight you with the same singular product line, neither of you are satisfied. So we’ve separated those roadmaps to say, “How can we understand the priorities of our on-premises server customers and how can we delight them? How can we understand the priorities of our cloud customers and delight them?” There’s still a lot of commonality between the products. The Job-to-be-Done is largely similar, but those things around the edges are now becoming different, and they’re becoming different on purpose rather than by accident.

Adam: As you went through that transition, I’m sure it shaped the way that you build your teams too. How are the R&D teams structured today at Atlassian? What types of disciplines are involved? What’s the size you try to keep teams at?

When you get diverse minds you get brilliant products.

Dom: When you go through a change like that, you panic about other things that will go wrong. It was weird, our panic actually worked to our benefit because we ended up worrying about things and therefore mitigating them in advance. So the actual change itself was relatively smooth. One of the things we learned was that the differences between our teams are not that huge. The mix is still the same.

We care about cognitively diverse teams. We have good mixes of designers, UX/UI, information architects, product managers and engineers working together. When you get diverse minds you get brilliant products.

Yes, we care about other levels of diversity as well, but we get the most amount of value from cognitive diversity. That’s the same whether you’re building on-premise or cloud. Where there are differences is in the engineering skillset. If you look at the engineering that we need for cloud products, where we have a centralized platform, we’re building many versions of the products, we’re deploying many times a day, and there is a different build and release cycle there compared to our server brethren, who are often building a series of features over a number of sprints and then deploying.

Your rhythm and cadence might be subtly different, but the mission is the same – we want to delight the customer. We actually have people that are trading across the two different teams, where they’ll go and work on our cloud teams for a period of time, learn some things, and then they’ll go and work in our server business. You can learn local subject matter expertise relatively quickly. We’ve built that into our onboarding, and that’s subtly enabled us to keep even our most experienced people on our R&D teams moving across those teams. That lateral movement is valuable for them and valuable for us.

How to facilitate, not force, innovation at scale

Adam: Atlassian is universally known for its culture. We see a lot of tech companies opening these “innovation labs”, and I know things like that make your skin crawl. At Atlassian, what do you mean when you say you have “a culture of innovation”?

Dom: The fundamental thing is we don’t believe in the lone genius. Great minds don’t think alike. If you get like-minded people, you will get somewhere really quickly but you won’t want to be wherever you are. It will not be a nice place. There’s a recent Ernst & Young report that says, “90% of organizations are solving problems so complex they have to be solved by teams.” One lone genius can’t solve them. We’ve taken that approach to our innovation.

The other part of that is, and this is where most people get a bit touchy, that the best ideas don’t come from the most senior people. There is no correlation between tenure, age or any other kind of old-school traditional measures of seniority and great ideas. In fact, I think there might be a reverse correlation. Some of our best ideas come from our freshest people, because they don’t know what they don’t know. They break through walls they didn’t know existed.

As part of building that culture of innovation, we’ve taken a different approach than many organizations. You mentioned the labs. They worry me. They get so detached from the core business. They often aren’t able to assimilate their ideas back in. Innovation rooms are (another problem). The idea that you need a physical space for people to go and innovate in on chalkboards and Post-it notes, it’s worrying.

The other one is kind of the token innovation. That we’re going to have posters and T-shirts and a PowerPoint presentation, and that’s often just to placate senior management and a board of directors. Our way is that innovation exists in everyone. You may have worked in an environment where innovation was beaten out of you, and so my job is to create a space that’s psychologically safe for you, where you feel comfortable bringing your best, innovative self.

The best ideas don’t come from the most senior people.

By building a culture of innovation and assuming that it exists in everyone, it links to our value of being the change you seek. What we say to people is, “We expect you to innovate every single day.” We’ve essentially got three pillars. Pillar number one is innovate every day, be the change you seek. If you see something you don’t like, it’s on you, and that creates incremental innovation. You don’t tend to get rockets flying to the moon from that, but it’s great momentum.

The second part is we do the more traditional kind of innovation week, 20% time. Some do that one day a week, some do one week every five, six, or seven. We leave it up to them to choose.

The final ritual is ShipIt. We find that it’s a cycle. A lot of teams won’t present a finished product at ShipIt, they’ll present the concepts, and then they’ll use that 20% time or innovation week to finesse it. They’ll use their peers to actually spar on that and seek constant feedback.

It just creates this mentality that our world is not linear, it’s not inputs, process and outputs. It’s circular. It’s very dynamic. When you understand what you can learn from others and how you can get feedback to improve whatever you’re doing, you get in this loop of practice and evolution that is way more powerful than any process. That builds this constant culture and expectation that what we did last quarter might not work next quarter, and that it’s okay to kill something that’s working to do something better. Don’t wait until it breaks.

Saying yes to diversity and no to bureaucracy

Adam: As Atlassian has opened offices in places like Japan, the Philippines or Europe, all these places have very different identities and cultures, do you try to control culture? How do you use these differences to your advantage?

Dom: The first thing is rid yourself of the fallacy that you can control it. You can’t, and in fact it’s probably the worst thing you can ever do. The minute you try and control culture, you’re trying to manipulate something that is natural and organic. It sets some really bad precedents and bad practices in place. The approach we’ve taken is that our values aren’t up for debate. Be the change you seek. Open company, no BS. Play as a team. Build with heart and balance. They are not up for debate, and so we hire for values in every location.

The Atlassian company values

There is a values interview as part of our hiring process, and that values interview has veto rights. You could be technically amazing, but if you’re an ass, we’re not going to hire you. It’s just plain and simple, and it means that in each location we are hiring people that are consistent with our values, but they will build their own subculture. I’m cool with that because I want them to bring their local customs and culture to fruition, because that gives us diversity and is very valuable.

What’s fascinating is in each of those geographies, in each of those sub-teams, you will find the way they share stories about our values is subtly different. That makes sense, because they’re from a different background, with experiences, and we embrace that. That enables us to scale that culture, but it’s not really the culture that’s scaling, it’s the values that scale. We have many, many cultures. You can’t control it but you can influence it, and the storytelling is our way of doing that.

Adam: At some point a startup is going to need program management, progression paths, management, etc. How do you maintain that culture of innovation when bureaucracy can begin to become a reality?

Dom: Don’t let bureaucracy become reality. I’m a fond reader of Gary Hamel, who talks about bureaucratic sclerosis and the debt that the economy pays by having bureaucracy. There are some elements of bureaucracy that are valuable, but most are steeped in 1920s ways of management and business, and the business I’m in isn’t that. We do everything we can to rid ourselves of bureaucracy.

We do everything we can to rid ourselves of bureaucracy.

I think of bureaucracy as friction. There’s a whole lot of positive friction in my business, similar to yours. If you get a designer, a product manager and an engineer on a whiteboard, they will argue the hell out of each other because they see the world through their own lens. That’s positive friction, and we call it sparring. Then there’s negative friction, which is bureaucracy. Process, sign-offs, business cases, all these things where you have to prove or substantiate what you’re doing, and you spend more time justifying it than you spend doing it. That’s just not valuable to me.

With career paths, we’ve opened a program around mobility to help people move into subtly different roles. It’s not the traditional climbing the corporate ladder, it’s getting breadth of experience and exposure, and having impact on meaningful work.

Adam: So working on different products or working in different ends of the engineering stack.

Dom: Absolutely, a whole lot of our platform people are transitioning to product roles. A lot of our product people have gone from one product to another. Some are working on brand new products, some are preferring to work on the evolution of older products. It doesn’t matter (what type of switch), but when they bring the richness of their historical experience and a different frame of reference, and you glue that together with a whole lot of people that have great experience in that product or area, that creates genius. That creates friction where you can create gold.

Adam: One thing I’ve seen be really effective is enabling people to feel comfortable moving from a management role back to a contributor role, or vice versa. The best contributors often come from management, and the best managers were recently on the coalface.

Dom: We’ve done a bit of that recently, and the value’s been amazing. We have one of our senior dev managers who’d been with us 10-plus years, and he just turned around and said, “I have no desire to be a head of engineering or a VP of engineering. I’m passionate about building amazing products that customers love.” His kick, his ego massage, is when he sees a customer comment of, “Wow.” That’s his return, that’s his reward, and so he moved laterally into an IC role where he got to go and build product again, and that made sense for everyone. He’s amazingly happy. We’re amazingly happy because he’s building brilliant product, that’s what his value proposition is, and our customers are even happier.

The thing that often gets in the way is bureaucracy. Some kind of HR process that says, “You can’t do that.” I moved last year from running our program management team into an IC role, because there was something I was passionate about, which was teamwork, and I wanted to solely focus on how we evolve teamwork. I couldn’t do that and run program management. A whole lot of my mates said, “Hang on. You had 14 people reporting to you and had this seniority and this position.” I don’t roll over excited by how many people work for me, I roll over excited and energized to go and start my day’s work because I’m working on something meaningful and impactful.

A playbook for building healthier teams

Adam: Your team recently published the Atlassian Team Playbook to share a lot of the things we’ve been talking about today. What’s the story behind it, and what’s the content like?

Dom: As we were scaling, that bureaucracy that you talked about was starting to creep in by accident, and we’ve never prided ourselves on being efficient. We’re not producing widgets, we’re producing experiences. We want to be effective and we want to be relevant. The playbook was born out of the idea of, how do we get our teams to scale and stay autonomous without adding layers of management? Smaller businesses, as they’re growing, can accidentally start adding layers, and they don’t add any value.

As we were doing that, we produced a whole lot of plays, ways that teams were working together that we thought made them more effective. The problem was there’s no correlation between high IQ people and high EQ people, and similarly you can’t just learn self awareness.

We looked at some successful project teams, we looked at some teams that failed, and we landed on eight attributes that we believe make for a healthy team. The idea is if you have those attributes in abundance, you’re more likely to be successful. It doesn’t guarantee success. Stuff will still go wrong, there’s still externalities.

We have this idea of a health monitor, and I bribed the first team to use it with coffee. I bought the team coffee, got them in a room and ran a health monitor. They got me to do it for another team, and then over the next few weeks, we did it with about 100 other teams. We have run with this model internally for about two years.

The Atlassian team Health Monitor evaluates eight core attributes.

We have three team types that we focus on: project teams, leadership teams and service teams. Project teams are cross-functional. They have a start, middle, and end, a shared goal. You ship some new product, experience or service, and then you often disband.

Leadership teams are setting the North Star, the vision, the direction. You’re there to be a coach and a mentor, and then ideally stay out of the way. Don’t micromanage.

Service teams was something we landed on quite late. The notion of queue management. You are providing a service to the organization, and you’re not necessarily owning your own backlog, but you have a queue that you need to respond to. How do you prioritize? How do you learn about the future so you can prevent things from going wrong, not just cure them?

The health monitor is a low fidelity exercise. Not tech, no laptops, no phones. Thumbs up for good. Thumb sideway for not so good. Thumb downs where you’re struggling. They rate individually the eight attributes, and then they come together as a team and discuss that. It’s great. You realize that everyone has a completely different view of what the team’s great at and what they’re struggling with, and as a leader I find it very powerful to have my frame of reference challenged. What I see is what I see, and everyone else sees something different.

Then, get the team to pick one area to focus on – and we’ve linked the areas of the health monitor to the plays. We packaged up the three health monitors and 26 plays in October 2016 and launched them to the world. They have got templates in them, so Atlassian customers get a little bit more value by being able to use some templates that are available in cloud and server, but we’ve made the templates available to anyone using any products. It’s completely product agnostic. We genuinely want teams to unleash their potential. Tools are good. You sell tools, we sell tools, but a fool with a tool is still a fool. In fact, you’ve made them worse because you’ve made them faster.

How do you help that fool be more effective? Any organization, small, large, of any industry, if you’re not evolving the way you work, you will not stay relevant. You will not be effective. The playbook enables us to stay relevant by assessing how we work together and finding singular areas to focus on, to drive improvement. Then we reassess and improve. We’re constantly changing the way we work without ever having large scale transformations. We have no change managers, transformation leads or change transformation programs because we’re changing every single day.

Adam: What’s one quick and easy way for someone to walk away right now and do a health check on their team?

Dom: If you go to the Team Playbook website, you will land straight in health monitors. Pick your team type – project team, leadership team, or service team. In there is the template, the eight attributes, and the natural recipe card of how to run a health monitor session. Get your team in a room with no tools, and run that session.

If you’re the person driving it, close your mouth and open your ears. It’s often the hardest thing to do. There’s no value in you coming out knowing what you knew when you went in there, so use the ears to be more of an elephant and less of a hippo. How can you just listen? What is your team doing well at? What are they struggling with? How as a team can you solve that? How as a team can we drive improvement? A lot of leaders leave those sessions with a to-do list for themselves, and that’s not the intention.

For building self awareness and focus, it is probably the most valuable tool or technique I’ve ever used. We’ve run more than a thousand across Atlassian teams. I’ve also been fortunate in my Work Futurist role to run a lot with outside companies. Large banks, government, small tech, startups, etc. It’s fascinating to see that no team has got it right, but the teams that take ownership of improvement and can have honest conversations about what they’re struggling with, they’re the ones that will be successful in the future.

Adam: Before we can build better tools we’ve gotta build better teams. Dom, thanks for joining us today.

Dom: Thanks for having me.