In their own words: how to be open to the world

This article is the last in a three-part series exploring what a culture of openness really looks like, warts and all, in the words of everyday Atlassians who are living it. Read the first article, and the second article.

If loose lips can sink ships, they can sink a company, too. Or so goes the conventional wisdom. But times are a-changin’. Consumers – and, indeed, whole economies – bear scars from firms that were less than forthcoming. Now, old-guard and forward-thinking companies alike are setting a new standard for corporate transparency and accountability.

At least, they want to.

Opening up to customers and the general public is scary. There is no recipe to follow. There is no guarantee people will be kind, or even tolerant, when you pull back the curtain and reveal what’s behind, warts n’ all. No wonder many companies stall out somewhere between impulse and action.

But taking the leap of faith has its rewards. Beyond the “halo effect,” entering into a candid dialogue gives companies deeper insight into customers’ needs, motivations, and expectations. I sat down with five Atlassians who have to weigh transparency against vulnerability every day. We discussed what’s hard about living by our “open company, no bullshit” value, how to know when you’ve struck the right balance, and why on Earth a software company would make its database of known bugs open to the public.

Scott Rubin joined Atlassian in 2018 as Global Head of Brand and Communications after long stints in similar roles at Google, Andreessen Horowitz, and others. He makes really good plum preserves.

Scott: When I first got to Atlassian, I was shocked. I was so used to paranoia as a first response to everything around reputation. I still struggle at times trying to figure out how open we can be when we’re talking publicly about things that haven’t gone well. How much information can we share without crossing the line into recklessness?

Emilee Spencer works with Atlassian’s ecosystem of partners and add-on vendors. She brings a global perspective stemming from extensive time spent studying in Lyon and Singapore.

Emilee: On the ecosystem side, it gets tricky when we know there are issues affecting Marketplace vendors but we also know that addressing them isn’t a top priority for one reason or another. It’s uncomfortable talking to them about that.

Pratima Arora has led product management for Confluence since 2017. A self-described “geek at heart,” she holds advanced degrees in both computer science and business administration.

Pratima: Saying “no” is so hard. Customers ask us for so many different things. And we can’t take up all of their suggestions because we have to look at where the market is going and where we want the product to be in the future. So as we balance supporting customers with building a forward-looking roadmap, we have to say no to ideas customers are really passionate about.

When you present your decision, not everybody takes it positively. It helps to explain why it’s not a fit with where the product is now or where it will be in the future. Being open about the rationale is critical.

Scott: It’s a challenge making sure we remain true to ourselves and our values, but don’t say something we’ll need to retract later.

Pratima: Product managers walk that tightrope every day.

Rick Bal joined Atlassian’s customer support organization in 2010 and now leads a team of more than 50 people. Ask him about the time he played drums in a “terrible” pop-punk band.

Rick: It’s really about partnering with the customer and building a relationship with them. Understanding why they want something, versus just saying “No, Jira can’t do that” or “That’s not what Confluence was built to be.” We always try to find a workaround or some kind of solution for customers. Sometimes, it’s saying: look, this might not be the right product for you.

Stephen Deasy heads up engineering for Confluence, Trello, and many of the shared services our products rely on. He prefers donuts and the really bad coffee sold alongside them.

Stephen: Openness isn’t free, right? We ask our engineers to participate directly in those conversations with customers, which is something they’re not specially trained to do. They come from a place of wanting to share everything they know about the issue, which is a significant investment in terms of their time. We also trust them to do that without going through legal or scrubbing what they say. So the trust factor has to be high, too.

Having engineers reply directly on support tickets or feature requests might seem like madness at first, but that’s the way the industry is moving. It started with open source projects, all of whose bug trackers are open to the public. Now, it’s a model most developers are familiar with.

Pratima: When you put your bug tracker out there, you’re acknowledging your software isn’t bug-free. And that’s just being real. You’re letting people know how you’re improving, versus trying to hide every flaw.

Stephen: Plus, when I can look at the issues and look at how often bugs get fixed, I can see the product is a living thing. I can feel confident about investing my team’s time and money in it.

Pratima: Maintaining a public bug tracker shouldn’t be taken lightly, though. It comes with a lot of hard work and it takes time.

Rick: I used to work closely with Jira’s bug-master. The first half of his day was just going through customer comments from the day before and really understanding the bug they’re seeing or the feature they’re requesting. I was blown away by the fact that we had a role dedicated to that.

So for support staff, having these channels of communication and feedback loops with our customers is amazing. We’re able to advocate for customers more effectively and make sure any stress they’re experiencing gets escalated to the right people.

Emilee: The open bug database is a great resource for partners and ecosystem vendors, too. If a professional services partner is working one-on-one with a customer, they can easily see any known issues. Or if we say we’re not going to implement a feature request, it opens the door for an add-on developer to fill that need.

Pratima: We could do more to bring our partners and ecosystem vendors closer. They’re kind of an extension of the Atlassian team. I see ways we could engage them in our development process and that’s an improvement we absolutely should make.

Emilee: Right. They don’t always get sufficient notice about changes we make that’ll break an API. With all of the different teams involved, there’s a good chance somebody isn’t aware they need to involve my team or isn’t thinking about ecosystem developers. Everybody ends up scrambling to figure out what’s going on and adapt.

Rick: I think we strike a good balance overall, though. If we ship a bug or cause an outage for a customer, we’re quick to own it and talk about what we’re doing to fix it. At other companies, it felt like I had to read off an approved script for those conversations. But here, we just set some guardrails and trust people to run with it and figure out the best way to help customers in that context. It makes us vulnerable in some ways, but it works.

Pratima: That honestly builds a lot of trust with customers. And trust has to be there because they’re putting critical data into our tools and rely on us in order to get their work done.

Scott: It’s not just that we want them to trust us. They are, in some ways, monitoring whether we live up to our values and I think that’s a positive, self-reinforcing circle. We’ve invited them in and we can’t shrink back from that without sounding like we’re full of shit. And I love that.