Atlassian on transparency as the secret sauce of collaboration

Connected digital technology is enabling the development of new patterns of collaboration in the enterprise. Some of these new ways of working have arisen because cloud and mobile technologies allow us to connect and collaborate even when we're out of the office. But others apply even to teams that spend pretty much all their time sitting at the same desktop day after day.

In a traditional enterprise setting, teams have tended to work separately and only communicate sporadically about what they're doing. Today's pervasive information sharing and communication makes it easier to keep constantly in touch. It then becomes possible to break down larger projects into more atomic tasks, and have them completed by teams made up of people drawn from different departments or locations.

Such patterns of working have become commonplace particularly among software developers in agile and DevOps teams. Their need to deliver rapid outcomes — in extreme cases pushing new software code into production several times a day — demands a high level of co-ordination among small, atomic teams, each of whom work on specific tasks within a broader project.

The practice of openness

Different rules apply to this form of fast-moving collaboration than we've seen in traditional enterprise structures. Jay Simons, president of Atlassian, whose collaboration tools are popular in the agile and DevOps world, explains that one of the most important principles is transparency.

Software teams actually need to work together with a different degree of openness than I think most other teams are accustomed to. The practice of agility and being more iterative is accompanied by the practice of openness.

This upends the traditional enterprise approach to providing visibility into work-in-progress. Traditionally, a document created in Word, or stored in the cloud, starts out private until it is explicitly shared to other named individuals. But that makes teamwork an afterthought, whereas it should be the default, says Simons:

Developers can't afford to work that way because everything that they're iterating on together, they're doing as a group. And so they start with this principle of everything is available with all of us. And then, we can work back from that to exclude people that we might not need to share certain sensitive parts of the project with.

Everyone can see it

So in the case of a work item created in issue tracking platform JIRA, or a document created in Confluence, Atlassian's information sharing platform, the default is that everyone can see it unless explicit exclusions are made:

If you think about Confluence, it begins with a page that's available to everybody and then you choose to secure it, from open back — as opposed to, when I create a new Google Doc, I'm the only person that can see it and I have to declare who can see it.

Especially where you think about millennials that enter the workforce, they're accustomed to more open communication, collaboration, connection. I think both large and small organisations are recognizing that that level of openness allows people to work faster and better.

3 pillars of teamwork

In support of this more transparent mode of collaboration, Simons identifies three pillars of teamwork served by Atlassian's flagship products Jira, Confluence and HipChat:

The team technologies that we create focus on three fundamental needs of teamwork:

Managing shared projects, deliverables, and deadlines — it's what Jira does.

Creating and sharing content. Where [cloud-based file-sharing platforms] Box and Dropbox are really more intended around storage and sync for content that's created using some other tool, Confluence is a system for actually creating content on the web. You don't need a storage mechanism because the web already is one.

Messaging and communication [via HipChat] is the third dimension.

So the three legs of shared teamwork are: managing projects and work; content; and messaging.

Universal teamwork

Although Atlassian started out serving developers, the company is finding that its tools are penetrating other enterprise functions as adoption spreads, says Simons.

The three kind of areas of teamwork that we focus on are universal for any type of team, whether you're working on a technology project or not. You still need better ways to manage shared work, creating shared content and communicate a message to different teammates.

It's certainly more common for an IT organization to introduce us, because they are the early adopters and also the champions of change through technology inside of organizations, more commonly. But it's not uncommon for different parts of the organization to begin a relationship with one or more of our products.

Atlassian provides security and governance capabilities — as well as scalability — to meet the needs of larger enterprises, but the core teamwork capabilities are the same for all sizes of organization, believes Simons.

A really large company is just a collection of more and more teams. If I'm a 20-person company, I've got 20 people that are a part of five or six or seven different teams. If I'm a 20,000-person company, I've got 20,000 people that are a part of hundreds to thousands of different teams.

Bottoms-up adoption

Therefore the bottoms-up adoption that has served Atlassian well will continue to help it expand its enterprise footprint, he says.

Ten or fifteen years ago, the technologies that you would use inside of the workplace were declared [by the] CIO — 'Thou shalt work this way.'

I think today teams are able to select the tools that will best address what they need. And so I think bottoms-up is pretty common. Certainly Atlassian's championed it.

But, you know, because we serve and support the team, we can start inside of an organization of 20 or 200,000. We can start with that small group of people, and I think they become champions and evangelists and demonstrators of better ways to work — and that's how we spread.

Atlassian therefore doesn't see a need for an explicit enterprise sales team, working with partners instead where customers require implementation or change management services as they roll out the product set more widely.

We have a small team that we call enterprise advocates, which is almost like a concierge service for really large companies. We can work with really large companies to help them understand that upgrade path, and [respond to] additional questions that they haven't found answers to on their own.

We also have a partner network that, in-region, can work with really large customers on that upgrade path.

My take

I spent several days last week at Atlassian's EMEA conference to understand more about the vendor and how its customers approach collaboration. This conversation with Jay Simons was notable for the insight about the importance of transparency when teams adopt an agile, iterative mode of working. He is right to contrast this with the traditional enterprise approach, where the default was to reveal as little as possible.

At first sight this seems like a small difference in emphasis, but when you probe more deeply you realize that it has a crucial impact on the role that collaboration plays. The traditional approach treats collaboration as an optional add-on to the core process. The DevOps approach — which embodies the agile, iterative, cross-functional, atomic structures that are likely to spread throughout the digital enterprise — treats collaboration as a fundamental element.

Earlier this year, I wrote a series of posts on the future of enterprise collaboration. The fifth and final post in that series is still not published, deferred while more topical commitments have taken precedence. In previous posts I debated where the core of collaboration sits — in messaging or content, embedded in applications, or centered on teams. When I return to conclude that series, it looks as though I shall have to consider a further possibility, that workflow is the core. Whatever, the rest of us can learn a lot about teamwork from developers.