How Atlassian Built a $10B Growth Engine
producthabits.com
producthabits.com
No, it can't. Atlassian's tooling is used by large teams. It doesn't make sense in a small team environment. In a large team of say a dozen people, can you imagine managing accounts/permission/access to a dozen services? That's over 144 accounts, plus billing, plus all the other stuff needed to make everything play together. Nobody wants that headache.
That's just the tip of the iceberg too. Atlassian already plays well with Github and other services. So you can have your cake and eat it too.
This is really the benefit of Atlassians wide product funnel at the top. JIRA might be the Worst Thing Ever, but it can be configured to needs and integrates well with most-everything. In a lot of Enterprise scenarios the most win/win solution can be using JIRA as your default and master data while teams and projects are using integrated too stacks.
That way your suits can have standard tooling across the board, your sensitive issues are all registered in an on-prem installation, and your dev teams are free to find The Right Thing for them.
Atlassian/JIRA is a platform as much as a product. With its integration story and plugin market you don't need to swallow it whole parcel, and it's easily an industry leader in that regard.
You just need the glue.
GitLab Omnibus has Mattermost integration, but you could also look at Rocket.Chat (and in all honesty Discord is a kickass free alternative to Slack).
Atlassian is free to use and invent what they need to provide a given feature.
Granted, it can take years, but compared to a collection of Add ons, "beats" a mix-and-match tool set.
JIRA's most powerful feature is that it affords for mapping businesses processes onto software. This is incredibly compelling to enterprise customers. Software that enforces workflows, procedures and requirements can be an incredible lever and JIRA's price point makes build vs buy decisions an absolute no-brainer.
The down side for the true end-users, those who actually use the software day-to-day, is that most business processes are awful.
If your experience is the hellish existence that I see strolled about on threads where JIRA comes up, I can say with near absolute confidence that it's because of one of three things:
* Your admin(s) set it up once and hasn't bothered to iterate on those workflows. * The business mapped their autonomy stripping processes onto JIRA intentionally. I'd guess that most of your work experience is similar. Process stifled nonsense. * You're on an instance that is serving too many people with too few resources. Shard your instances folks, the money for extra licenses is wildly cheaper than the human time you're wasting waiting for stuff to load.
Somehow, they managed to accumulate the negatives of a flexible product (resulting in poor/incoherent UX) and the negatives of rigid assumptions regarding workflows (try modelling staggered deployments in different datacenters/environments spanning multiple sprints... good luck!).
Going forward, I expect Atlassian to cater to rigid organizations and neglect those who design their own processes (whether lightweight ad-hoc or complex custom ones that don't fit what Atlassian Sales can understand).
There is an enormous amount of hate directed at JIRA that is a side effect of customizations created by admins. People abuse the customizability and their own internal users suffer the consequences.
Atlassian's own public issue tracker is using a near-default issue display screen. Nothing is "below the fold" for me on this issue and on a small monitor: https://jira.atlassian.com/projects/CORE/issues/CORE-1055
> Last commented: 1 year, 13 weeks ago
> There are no comments yet on this issue.
Maybe a large part of the hate is genuinely about the default configuration and UX.
It appears the issue in question was commented on 1 year, 13 weeks ago. But the comment isn't visible to the public, thus the "no comments yet" message.
I showed the CTO and CEO ZenHub and we're off to the races.
It’s probably inevitable but a policy requiring strong justification for and regular review of any “aftermarket” changes might slow down or reverse the descent. The closer it is to vanilla the easier it is for (almost) everyone. Managers and workflow czars (nice one btw) of course would be inconvenienced but they should be comfortable making really strong justifications for making the lives of developers harder just to make their reporting smoother.
I attended a talk by a Netflix employee where they talked about a sort of organizational immune system to aggressively prune bureaucracy and policy by forcing it’s existence to be regularly justified. It helped me connect the dots and realize that allowing heavy customization was as much a poison as it was a boon.
One axis is number of people actively using the tracker for a single project — I personally think that threshold is around 50 people^1. Another is workflow complexity — very few tools are as capable of mapping business processes to software as JIRA^2.
1. Careful, there's another threshold at which JIRA becomes painfully slow. At that point you either move to something that's less adequate in nearly-every way but scales or you start splitting JIRA instances by department or project.
2. Careful here as well! Poorly created JIRA workflows are probably _the_ #1 reason people hate using it. Users learn a highly customized JIRA workflow and think it's absolutely bonkers that Atlassian did this to them, when really it's their company's customizations that are causing the pain.
If you look at the most recent changes to Jira, like the Agility boards announced at Summit, it’s about starting from as much flexibility as Trello and expanding to as much power as standard Jira (if you need/want it).
Disclaimer: ex-PM on Agility boards, no longer at Atlassian, opinions are my own.
Jira is a painful to use, especially compared to trello. They own trello now, so I hope they don't mess it up.
Its put in with reluctance rather than enthusiasm.
And to be honest, it's a process tool. Dealing with processes is boring.
Jira is better than bugzilla and trac. And much better than some tools, constructed from manure, from big IT companies and sold for very high price tags.
It's sad to me that they lost momentum. I think they got stuck trying to overcome tech debt and bug fixes and feature requests started to pile up.
From time to time I keep an eye on CommonMark implementations and fantasize about writing an MVP to replicate parts of Trac by composing existing tools. Unfortunately there are like 5 other things I'd rather do with my free time.
IMHO If you are a small startup and can be self disciplined, you don't need Jira. It is more for enterprise setup where accountability/responsibility has to be generally enforced.
I think this is some kind of natural law: any sufficiently old enterprise system tends towards becoming an ad-hoc, bug-ridden, poorly specified workflow engine.
Those reports are not generally being used to make sensible decisions, but they make management feel more in the know and in control and thats what really drives sales.
Jenkins comes to mind, Jira of course, and just about any other Java project's website still looks like it is from the 90s.
Also, all the big internet companies use Java, basically. You're using Google, Amazon, Twitter, Netflix, etc. products and you're using Java. Do you also hate those? :)
Furthermore, Java is mostly server side at this point so I'm not sure your UI complaint is really valid...
If you're using JIRA for stuff that Trello works for, then sure.
What JIRA does and does exceptionally well: grows with your organisation. You can start using JIRA for a simple ticketing system with 3 devs, then continue using it through 100x growth and still use it with multiple product teams, multiple development teams, overlapping projects, CI, code review, wikis, reporting tools, and so on.
If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot.
JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.
The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.
(Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )
This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason...
And you're also stuck carrying around all the features you don't use...
Works as a general rule, too.
But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.
The agency I work at uses these tools together with ovur clients, as well as internally on different levels.
We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...
And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not.
I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.
I am not sure who the 'management' would be in their case.
Just throwing something out there... But I wonder what the spread of these "smart" people is across "development" and "management"? The parent comment seems related to this...
> JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealing.
The "tool" doesn't need to be overly "opinionated" just like a programming language, I want a tool to be flexible. It's my responsibility as the architect to constrain the tool/language for my environment.
Now, if there was a way to grow its user interface along with the organization's growth, it would be fantastic.
I feel like, as an industry, we should be moving beyond that at some point.
I've seen one dev excited - the one who tested other tools and picked Jira because it checked off on all the "features" needed. It really did handle the arcane and complicated workflow we had. But besides that few liked it, though it was a mix of hating the slow and unresponsive UI and hating the arcane process.
Instead of adopting a sound process, customers will take an overly complicated business process and make the tool conform to this process. And please note that in this cases how you manage your code workflow is, in fact, the business process.
Any tool will struggle - often it's the process that's cumbersome and not the tools.
For me, I'd love to have a flexible-enough tool for small to medium sized orgs that encourages a modern lightweight process and discourages ad-hoc process sillyness. Sometimes having a tool gently encourage better practices among all participants is a useful thing.
Can you expand on that? I've never seen a manager use it well. They use it to generate numbers for their reports for the people they report to, and it doesn't tend to matter what those numbers or reports actually represent. For example, it's very easy for process to make velocity numbers complete hogwash.
Basically, as far as I can tell, it's great and being able to tell you what you want to hear, and not very good at providing usable insights that increases productivity, but people don't notice because they're hearing what they want to hear.
For my money, the #1 benefit to scrum is improved visibility to stakeholders and any productivity gains to the dev are the result of them being able to work on things in the correct priority order due mainly to benefit #1.
One thing I definitely don't have is any managers living in it. It has all kinds of (useless, IMHO) reports it can spit out, but we don't spit them out, other one for time tracking some particularly-tagged issues (for the SR&ED tax credit program).
What is really awesome though is looking back through issues (and in general, JQL). For example, finding any re-opened bugs:
type = bug and (status changed to reopened after 2017-01-01) and project in (PROD1, PROD2)
project = PROD1 and fixVersion = "2.0" and affectsVersion != "2.0"
This is very anecdotal. To see JIRA used well, you need both management which is willing to invest the time and effort necessary to learn the ins and outs of configuring JIRA, as well as competent and flexible stewardship by the admin team to enable desired configuration in a way which fits in with the rest of the instance and doesn't pollute it. If you pay attention to recent JIRA releases, Atlassian is trying to enable management to make the changes it wants to make without resulting in global pollution, but either way, you still need management to personally buy in.
I've seen everything from managers who refuse to customize workflows beyond "todo-in progress-done" to managers who use post-it notes on the wall for their "real" agile board, and then copy the changes by hand into JIRA issues to communicate status up the ladder. If your company's management isn't buying in, your company needs to either replace the managers or replace the tool, instead of trying to fit round pegs into square holes.
Other tools, fogbugz, trello, etc are very good at what they do.
Invariably though when you get enough projects that are complex enough (not always big), JIRA has been the only thing that could take a bite out of managing the details like few others.
JIRA also can be greatly simplified to use but most users don't do this. The JIRA core offering is what I recommend to folks. JIRA is heavier for dealing with heavier projects.
On the flip side. Having a search engine of every issue and decision, be it design, system, implementation, roll out ticket for every project in a company is second to none.
I recently assisted a client in their systems design and growth from from 0 to 50m revenue in 4 years. It feels strange and wondeful to have every decision made in one searchable place, on one time line for every major piece of software or system implemented for them.
Most start from scratch projects can be nicely managed in Trello et al.
Generic search alone isn't the feature, or the benefit. None of those options listed have a deep enough search. GitLab and GitHub aren't a project manager - projects that are manageable in Git* likely aren't complex, or enterprise grade.
I have tried nearly every product in this arena as well over 20 yrs of dev in different types and sizes of projects. JIRA begrudgingly is my neccesary evil. I hear nice things about Pivotal Tracker as well, just didn't reach my sphere of folks when I was looking.
I can see the appeal of that. That is a killer feature for me. My team currently runs what I find to be a pretty lean and clean workflow using Trello, Github (for source control and issues), and Wikimedia for documentation. (Oh, and can't forget Outlook for release scheduling.) Having all of that in one place would make life easier.
On the other hand, not having a monolithic service handling everything has forced us to pay attention to our workflows and practices and keep them sharp.
But the team is small. If we grew or had to manage more projects across multiple teams, this would be really valuable.
I used FogBugz for almost a decade until the most complex projects I was working on dragged me into JIRA. I miss FogBugz' email first interface.
My Current stack is JIRA/Confluence on demand, the integration in the WIKI is simply too good to overlook. For product roadmapping I use Aha.io integrated into JIRA.. it's so far a more capable product than JIRA Portfolio, JIRA portfolio doesn't go high level enough. Harvest in the mix for easy time tracking.
The investment of time in integrating projects between Aha and JIRA so far has been a big payoff. We can literally start noodling with ideas high level, and as soon as those ideas cross the line into an epic, we have the sprint ready to go and automatically created in JIRA.
While it wasn't as smooth, the incredible detail we can manage things that need it, while leaving other simple items to hop through the steps that aren't needed was invaluable.
* The idea of the "Atlassian Ecosystem", in that buying more of their services seems to work better.
* On-premise for most of their tools
* Pricing. For example, Bitbucket Server - $26,400 for 500-1000 users /year [1]. GitHub Enterprise - $2,500 per 10 users / year [2]. Self-hosted GitLab - $39 or $199 per user / year (Starter compared to Enterprise Edition Premium package) [3]. If at a 1000 users, that is $26,400 compared to $250,000 or $39,000/$200,000.
* "Other big companies use them"
* "Reporting and metrics"
* "There is a plugin for that"
But, I and most of the other developers I have worked with hate every single Atlassian product we use. JIRA eventually turns into a micromanagement tool with all of the customization people think they want. People seem to think that because it is customizable, it will solve their problems. It always seems to take up more time and resources to try and bend their tools to do anything useful than it is to just say, "well, I guess we don't really need that".
[1]: https://www.atlassian.com/licensing/bitbucket-server
https://bitbucket.org/product/pricing?tab=host-in-the-cloud https://github.com/pricing
Personally, I don't mind JIRA and the Atlassian toolset as they are so much better than what we used to use in the old days.
Processes (agile) and UIs (kanban) have been much more standardized in software project management and only now does it seem like some companies are coming up to give you that 90% out of the book with 10% the overhead/ management. Pivotal Tracker came close.. Clubhouse.io is the one I've seen doing it best.
They have quite different DNA. Tracker grew out of Pivotal Labs and it is mostly molded to how Labs and R&D teams do their daily and weekly work. To me it seemed constricted and limited until I came to work at Pivotal; now it makes sense.
Disclosure: I'm an Atlassian employee, but I had these opinions before I started.
Have never been able to use trello effectively with any clients. It's simply too open-ended on its own. "Issue trackers" (like Jira) have some semblance of workflow predefined, and act as a decent guide for people who are not "project managers" to still bring some degree of order/structure, with the benefit that that structure was actually defined by someone else who thought about data/structure/flow/etc.
So what is this site anyways? There's no About page, no contact, no ownership information, no author, nothing. Looks like an advertisement to me.
I have a theory that much of the success of web-based companies isn't due to the internet's reach itself, but because they can actually harness programming to business. Make something happen; check for something; modify everything. Of course, there's always problems with programming but it's so much easier than doing it any other way.
But traditional businesses cannot reap these benefits, because they cannot make IT central. They can't be IT first. And they lack the talent and experience to handle all the problems of programming. Therefore, it is the new web-based companies that know what they are doing (with programming) that win this.
The quote above is a great example: it's hard to integrate acquired businesses, they usually just become a messy "conglomerate". What if you could actually integrate other products and services into your products and services? With programming, it is possible, whereas it wasn't really before.
There are still problems - and other commemts highlight how the UI has suffered. Indeed, enlarging a codebase inevitably has much in common with a messy "conglomerate". But it's so much easier than doing it in any other way than with programs (i.e. traditional businesses).
(Atlassian's products also help other businesses run on programs, but that's not my focus here).
Other examples include filtering and search. Google has raised the bar so high in both gmail and core search for how a query should work. Jira says fuck you here is JQL, and it isn't at all obvious why.
We are a large organization, and had an end of year crunch so naturally when you need to pinch the absolute most productivity out of your workers, typically process is the first thing that goes.
We just had our most productive 2 week sprint in over a year, by a mile. Instead of Jira, we busted out the dusty whiteboard, and used this amazing technology called an expo marker to write down what we were working on and who was working on what. It had amazing visibility too -- our manager could stop by at any time and see with his own eyes what we were working on -- all without having to log in! The best part? We got to ditch the meeting to plan the planning, the planning to plan the week, and the retro to go over the week to start of the next week's meeting to plan the planning. We got back like two entire days, and we didn't have any 9:00 AM context switches when most of us were in the zone already having to give a benign update that could have just been communicated via slack!
Some of this is sarcasm and I do understand why managers and leaders reach for Jira, but seriously: Why did we stop using the whiteboard. If you need visibility into this crap, hire someone to do that. You have analysts for your business, why not have an analyst for your tech? It doesn't make us more productive.
Because you can't do the following things without doing something other than "the whiteboard":
1) You can't share it
2) You can't back it up
3) You can't search it
And that's just for starters.
Shall I go on?
> 2) You can't back it up
The number of photos of whiteboards I've taken over the years beg to differ. Point 3 is certainly valid. Whiteboards definitely don't work for remote teams.
Because whiteboards aren't visible outside the rooms they're in, and they don't save histories of what was written on them in the past. If your org is scaling beyond a single geographical location, then you need some kind of system to communicate status to stakeholders elsewhere. Email and Slack are nowhere good enough for that; a ticketing system is absolutely vital.
JIRA has an uncanny way of attracting to it a very specific (and valuable) person inside organizations.
I mean the person who is obsessed with the creation and quantification of knowledge worker processes that are subtly complex. This complexity naturally gives plenty of fodder and massive surface area for engagement and features —- one can spend hours tweaking JIRA workflows, running reports, and playing with the query builder. And we all know that once a user is engaged past a few days you’ve got them, almost like a kind of pair bonding. They have bonded with your software, and they’ll be forced to spend their days in it. If there is some ritual like work involved all the more better.
I’ve seen these guys come in from other organizations where they’ve used JIRA and the first thing they do is push for its adoption and use. There could be plenty of other things to tackle and I’m not here to make the case JIRA is or isn’t a good tool, has value, or is more or less important, I’m just sharing my observations. When you’ve literally made it your job to be the JIRA master, you are in fact more concerned with the performance of the work than the actual work product itself. It’s like the difference between introverted and extroverted personality types. Some people come in and want to get their hands dirty with the product and code, while others want to setup JIRA and start tweaking workflows.
Another brilliant thing I noticed they did was to optimize the scrum display for large TVs. Many issue trackers and other tools simply don’t look good (not readable) or are not functional on a massive 70” screen. The purpose of this is clear: for standups and planning meetings where it is used in a group setting (usually by the JIRA advocate/master).
Another big thing is the daily e-mails. It’s a way to show your boss and co-workers you’re doing something without telling them directly. And it makes people feel good to see activity, regardless of what is actually being done, it’s often times more important that people are working together, as 90% of all work done in JIRA is irrelevant anyway.
People talk bad about JIRA and despite its flaws you’d do well to study its workings if you are at all interested in building a similar B2B or enterprise app that requires a certain manipulation of the end user.
I don't believe this. There were plenty of competing Open Source tools out with the same problems. I hated every single one of them and so did other developers I know. Perhaps developers preferred Jira because the management could be told they'd have to pay a qualified contractor for customization instead of torturing the developers with that kind of work?
I've only had luck with management (analysis and planning) of ticketing systems when we treat this observation as law. Either you measure what you have the data to measure, or you convince the developers that maintaining some part of the data is useful to them on a daily basis. The third leg of that stool is realizing that graphs and trends are for asking better questions, not for making decisions.
Everything else comes down to a weak appeal to ethics. The problem is that a lot of devs either have or think they have a richer sense of ethics (not necessarily better, but more considered) than the people who want the data. So these appeals come across as tone deaf.
This was used for > 10 years (for a few 10000 tickets) AFAIR until it got replaced by Jira. It worked well and was accepted (or so it seemed) because it didn't really interfere with the typical way of doing things till then (e-mails) and offered minimalistic features on top.
Like the sibling comment, my own encounters with it have made me think more of the deli counter...
I don't doubt that this is the case. I worry that this begins to approach a "cargo cult" manner of thinking about development.
I can't help but wonder if this trend favours younger developers, who may not remember the days before Scrum became such a widely-practiced management style.
>Like the sibling comment, my own encounters with it have made me think more of the deli counter...
No doubt. Instead of being judged by lines of code, the deli worker now has to concern themselves with things like "velocity" (in which case, Jira has become a prime tool).
Vendors come in and bullshit your bosses and the purchasing authority about how awesome their tools are and all the things it can do.
By the time the developers catch wind of it the check has already cleared, and they -have- to use this tool because someone with firing authority paid for it and you're not going to get away with embarrassing them by calling them on their bullshit (young me tried, young me failed).
I'm not aware of any development team that consciously picked Atlassian. Atlassian gets picked for them. Their success is in selling to the management chain, not in being a good product. Because they aren't (but then neither are many of their commercial competitors).
in other words, they found a market need others ignored, and they served it.
I work at another ASIC company (Storage Industry) and we use JIRA as main issue tracker; JIRA feels very tailored for ASIC, at least the version at our company
Disclaimer: ex-Atlassian
Spartez has obviously been a great partnership but "large bits of their core offering" is inaccurate. That's not to deminish the efforts of the people involved. It's just materially untrue for most values of "large" and "core".
It's somewhat scary the breadth that AWS has in their ecosystem now; however, Bitbucket is wrought with issues like:
- no large file collapsing, i.e. lock files
- random downtimes ( I wonder if they actually meet their SLA )
- feature requests on boards where Atlassian members ask why x is needed, followed by a slew of +1's, to only see someone ask 3 years later, "where is this at?"
I'm a jaded Atlassian user who believes they buy competition and then stagnant the product's evolution.
Positioning it more like:
- It will save us X amount of time on average
- Give us better security through IAM
- Reduces fragmentation across org software
sells a lot better to people with credit cards than, "I like it more"
What product do you think Atlassian has bought to stifle it's evolution? Bitbucket specifically was a product with 50k users and Atlassian has grown it to Millions. Buying a competitor just to let the product stagnate and die makes rarely sense in business.
Hipchat could have easily taken the space that Slack exists in. Lack of product vision and resources dedicated to the project ultimately led a non-existent competitor to own the entire market.
By the way did you see Trello is now part of Bitbucket as a default?
What exactly was HipChat competing with in the Atlassian portfolio when it was acquired? Nothing. HipChat was three people when it was acquired. It was over 100 not long after. That space grew so fast that you could argue maybe Atlassian should have put 200 on it. Regardless, it got the biggest investment of any group chat tool in the game at that time. Slack did an amazing job in the viral growth front. Credit to them. Atlassian is beefing up HipChat for enterprise/BTF and launched Stride for everyone with an email address and a need for something more focused than slack.
I agree that there are better services if you don't mind running on other people's infra. Behind the firewall Jenkins I'm not sure about, I haven't tried it in ages.
I interviewed with Mike and Scott when there didn't seem to be many other people involved. A few days later the company I worked for started the process of getting acquired.
I tossed up what I thought my share options might be worth against two guys who seemed to be just out of uni with a bug tracker.
I called them back and said I'd stay where I was. My options were worth nothing. Joke was on me big time!
Later on lots of my dev team ended up working for Atlassian and I thought it might be time to check it out again. I went for an interview and was told I wasn't smart enough, despite the fact I'd already mentored a bunch of their devs.
At least they gave me an interview. Most places don't 'cause I don't have the book learning to get past HR.