Worked there from 2008-2013. So early-ish employee here. I still have a chunk of shares from the original ESOP program. Saying that for full disclosure because I'm biased and this feels like a hit piece to me.
When I worked there, they disclosed all financials in our internal Confluence site. There was a policy of full transparency with the employees. The owners (Mike and Scott) had impressive business discipline. They were profitable every quarter. They had many many opportunities to get vc money and go wild. When they finally took VC money, It was a modest amount ($60M I think) and the purpose was explained to us as setting up an ESOP program and putting Atlassian on the path to go public.
A year or two later, Doug Berman, the founder of Great Plains software became chairman of the Atlassian board. He gave a presentation to all of the employees at the Sydney office. One thing that stood out was that he said, it's actually bad to be profitable when you're growing. I'm paraphrasing here but he essentially said, you're leaving growth on the table. His thesis was growth is more important than profits.
So whether you agree with that or not, that is obviously the idea they are operating on rather than uncontrolled spending and helicopter dropping stock on employees heads out of desperation.
The idea that growth is better than profits was in-built into Atlassian's proposition to shareholders, ultimately.
The slow and steady mentality is fine, but we see over and over that it isn't what the market wants. A private company or a high risk growth company, those are the two options for a software company.
Either that or they'll be taken over. They're revenue now is just a $2bn, so that "grow grow" mindset from 10 years ago did not work out. In theory, a steady CEO could try to steady at that size with a nice margin. But, actually declaring and pursuing that would mean halving the companies market cap to a "normal" P/E of 20-30X.
At that price (say $20bn) one of the big software companies would just buy them... for their own growth targets.
Moderation has no place in the public markets as a software company. It's remarkable how unstable a stable condition is.
What's wrong with having a small or medium company? Why must a company sell its soul for the chance of becoming a money-printing behemoth in the future?
I understand that being small leaves you vulnerable to the predatory tactics of big players, but I see that as a consequence of lax regulation. There are too many mono/duopolies already, and the bigger they get, the harder it will be to split them apart.
> I understand that being small leaves you vulnerable to the predatory tactics of big players
This, I think, is the core of why. It's not that being a medium sized publicly traded company is immoral or unprofitable - it's that in a public market your stock is priced on future earnings and choosing to be smaller than possible means your tech can be bought for cheap. If you choose to stay smaller than maybe you could be - you're leaving ROI on the table in a lot of peoples' eyes (even if you're right and you'd lose money trying to get huge). So, as your stock price drops off to reflect the expectation that you're not going to get super impressive earning growth, you start to look appealing as an alternative to developing technology for an industry giant. Why spend $5bn over 10 years to develop competing services when you can borrow $5bn today, buy atlassian, get a tax break on the debt and start making a play for market dominance with the atlassian tech?
If you want a small or medium company, staying private is a more sustainable approach.
Well, it is fine to be a small enterprise, but unless you have a huge moat, you run the risk of a different growth-at-all-costs competitor (not necessarily a giant) coming in and vacuuming up all your customers.
Salesforce vs. Siebel being a great example of exactly that.
> Salesforce vs. Siebel being a great example of exactly that.
While I agree with your statement, I had to look that up because it sounds interesting. In 1999, the year Salesforce was founded, Siebel was the dominant player in the CRM field, holding 45% of the market, so not precisely a small company.
More than a budget war against a deal-with-the-devil startup, what killed Siebel was its inertia. Siebel sold expensive in-your-premises software, while Salesforce sold SAAS, and emphasized a cheaper cloud model. Siebel didn't react until 2003(!), when it released its first cloud version. By tht time, the expertise of cloud solutions of Salesforce made Siebel look like an amateur.
Siebel surpassed 1 billion revenue in 2000, while Salesforce did it until 2009. They had their chance.
I still agree that even if a small company did everything right, another one with more money and no fear of heavy losses would eat their lunch even if their product was inferior.
I'm not arguing with you, I just like talking about this, because Siebel himself has engaged in a huge disinformation campaign about what happened (he wanted to save his reputation and eventually launch c3.whatever). I've even personally listened to him bitch about HBS/GSB case studies about Siebel.
>In 1999, the year Salesforce was founded, Siebel was the dominant player in the CRM field, holding 45% of the market, so not precisely a small company.
Sure, but CRM was a new market back then (many argue that Siebel invented CRM) and Siebel was roughly equal in revenue scale to Peoplesoft and c. 10% the revenue scale of Microsoft. It would be very hard for anyone to argue that they ran out of space to grow (vs. choosing to slow down growth for profitability, especially in light of the dot-com crash)
>More than a budget war against a deal-with-the-devil startup, what killed Siebel was its inertia. Siebel sold expensive in-your-premises software
One great way to stop being an expensive piece of software and to grow faster is to lower your prices (but then you run the risk of becoming unprofitable).
Also worth noting that in 2000, Siebel spent c. 33% of revenue on Sales and Marketing, while Salesforce chose to spend 500%+ of revenue in the same period.
>while Salesforce sold SAAS, and emphasized a cheaper cloud model. Siebel didn't react until 2003(!), when it released its first cloud version.
Again, Seibel chose to spend 13% of revenue on product development in 2000. Easy to crush competition, but only if you're willing to spend for it.
>Siebel surpassed 1 billion revenue in 2000, while Salesforce did it until 2009. They had their chance.
Exactly, and choosing to harvest profit out of that $1bn of revenue too early is what did them in (though arguably, they are still probably something like $1-2bn of market cap for Oracle).
Seibel is and always will be the perfect example of disruption/the innovator's dilemma, which ultimately boils down to 'if you're comfortable with your current profits and not worried about growing top-line revenue, you will likely lose both.'
Nothing is wrong with it, I'm just predicting that this isn't a sustainable state for a publicly traded company. I don't think aggressive antitrust is likely and I don't think it would change the above regardless.
Markets pull towards potential, and the potential of Atlassian is valued higher than it's stable state.
It's not just that. The job of the companies is to make the most money using the legally available means, and the job of the government is to create regulation that makes "good" behavior profitable and imposes heavy penalties for disruptive things.
Except the government got addicted to printing money and throwing it around to boost GDP (and taxes) through bullshit business models and bullshit investments. They literally created framework where being an overstaffed money-bleeding behemoth creates higher returns for the shareholders than being a lean-and-mean niche business.
> What's wrong with having a small or medium company? Why must a company sell its soul for the chance of becoming a money-printing behemoth in the future?
If you don't go the unsustainable blitzscaling route you'll be outcompeted by those who do, just as Atlassian did to plenty of smaller, more sustainable competitors.
> I understand that being small leaves you vulnerable to the predatory tactics of big players, but I see that as a consequence of lax regulation.
That's nice, but that doesn't make it go away. Do you have a plan to make the regulation non-lax?
Not necessarily. If your company has strong fundamentals, for example Microsoft, then blitzscaling is not needed because not even a free alternative can compete with you. And if you don't have strong fundamentals, you really shouldn't be taking investor money anyway. Blitzscaling is just an exciting term to align founder and investor incentives (which tend to be at odds with one another)
Take a look at o365. Planner is an identical product to Trello. They're buying GitHub which competes with Bitbucket. Sharepoint & MSoffice are alternatives to Confluence. There might not be an equivalent to Jira but the Microsoft machine is increasingly muscling into their turf.
> but we see over and over that it isn't what the market wants.
What the market wants is short term growth and I firmly believe that is what is destroying our economy and the market.
Instead of building pillars and companies that outlive the founders, we have short term cash grabs. We have VC firms buying up our existing pillars, gutting them of any valuable assets, saddling them with debt, and then selling off the carcass. We have firms buying up real estate and creating or exacerbating scarcity to drive up demand and prices. We have shifts towards subscriptions and quarterly profits.
Perhaps, but I think on this instance... this short-termist mindset has a basis.
What kind of a 100 year future does Atlassian have? Jira certainly isn't a 100 year product. Software is so fast... IDK. The pox is not just a product of greed and malice and nothing.
> What kind of a 100 year future does Atlassian have?
We're talking about a company that produces products that are widely used. JIRA is not the issue, but the company that produced it. 100 years is stretching it, but I would believe that Atlassian outlasts yahoo.
Probably because the valuation is currently 10x revenue, and was previously more like 70x. "Only" is probably because the parent still feels like Atlassian is highly over-valued.
> growing 30% YoY for the last 3~4 years alone. This is unheard of in any other industry/market.
It has been common for the leaders in every other market throughout commercial history, as it pertains to corporations of large size. What you're looking at are presently old industries and comparing them to newer, that's where your mistake rests.
Walmart did it. Sears did it. Kmart did it. Best Buy did it. US Steel and its components did it. The various automobile majors did it. Standard Oil and the other oil majors did it. General Electric did it. Caterpillar did it. Pan Am did it. Many of the railroad companies did it during their time. McDonald's, Starbucks and most large chains do it during their expansion->saturation phase. Coca Cola did it.
It's exceedingly rare to find a large corporation that didn't bang out 30% growth years for a decade or more to get as big as they got.
One day, decades from now, "cloud" will look like a big dead industry too, and people will talk about how it never grows fast. Just ask the people that used to make business software you install onto PCs.
> And has been growing 30% YoY for the last 3~4 years alone.
Growing revenue while still not making a profit is not impressive. If you give me $100 today I can go out a buy $100 a pair of new shoes, and sell it for $70. Give me $200 and I'll go out and by two pairs of shoes and sell them for both $84 (total)! Keep giving me money and you'll continue to see this growth I promise!
> This is unheard of in any other industry/market
Given my example above, that should be a warning, not a sign of success.
I find it mind-boggling that people can really not even grasp that growing revenue with out demonstrating you can transform that revenue into profit doesn't mean all the much.
Grow profits every year by 30% and I'll be impressed.
Atlassian makes zero profits because it reinvests them in growth (hiring, acquisitions). The common sense here is that you return profits to shareholders only if you can't grow fast enough. That's the case for a lot of other industries where you have single digit growth in good years. But if you can grow 30% annually, you bring much more value if you reinvest your profits.
>It is when you’re a software company and the marginal cost of the goods is zero.
$600mm annual sales and marketing isn't cost of goods but the method of accounting that I subscribe to includes such costs as a fundamental cost of production delivery.
> If you give me $100 today I can go out a buy $100 a pair of new shoes, and sell it for $70. Give me $200 and I'll go out and by two pairs of shoes and sell them for both $84 (total)!
Hilarious that you use the analogy of shoes. This is exactly the problem. Great explanation on this concept:
True, but it is not unheard of for a software company. In fact, it's expected. Hence the valuations for software vendors compared to manufacturing, retail, etc.
This phenomenon might to some degree be a function of the board’s veto power over the CEO. A primary reason you typically go public is to grow, so by default at IPO you’re a “growth stock”. But from that point on, its difficult to ever make a transition to a steady, sustainable “dividend stock”, especially as a tech company. If you try to, the stock will tank, all the “growth” investors will get mad and you (the CEO) will probably get fired by the board, and they’ll bring in a new “growth” CEO.
Fundamentally, why would someone buy a stock of a company that doesn’t eventually make a profit or offer some sort of dividend? Seems like Atlassian traded profit for staying power, but can they leverage that staying power to bring value to their investors?
People buy growth stocks because they can sell them for more tomorrow, it's often a bit of greater-fool theory in play.
For the successful companies that do grow into a dividend company, they often have valuations that far outstrip their eventual settling location at some point in the trajectory.
The idea is they'll eventually get purchased, or have a profit and dividends. But if you're growing so fast it makes sense to focus on that over profitablity. Most investors would rather have a 1.40, next year than a dollar today.
Directly related to that, if the expert they hired to the board that led them in this direction was from Great Plains it useful to note that Great Plains exited by being bought by Microsoft.
> it's actually bad to be profitable when you're growing.
I've seen this happen so many times:
- profitable, down to earth founders generating net profits
- VC approaches said outfit and tries to gather as much info
- VC realizes said outfit is difficult to emulate and break into market
- VC invests and starts demanding they run at a loss to grow quickly
This works well when interest rates are low, and VC is not under pressure to deliver returns. However, when capital suddenly becomes slightly expensive, the whole house of cards start to crumble taking down the good business with it.
Neither strong prudence or optimism helps here. Once you start running at a loss post-VC money, you no longer control the destiny of your own company you started.
Let this cyclical downturn (likely to last for 5 or more years) be a lesson that the previous generation learned. If you are not making growing net profit (Revenue - COGS), you are no making period. Not so while ago people were arguing that debt is an asset and cash is a liability. It's always amusing to me how quickly people denounce gravity are impacted by it.
- Your entire theory relies on VCs having some power over decisions being made at Atlassian. That isn't the case. The founders of Atlassian have always been in control. After taking VC money and going public, they still have over 80% of the voting shares [0].
- A downturn of 5+ years would be the longest downturn in the USA in the last 100 years [1]. Anything is possible but it's unlikely to be that bad.
GDP contraction won't last five years. But it will be longer than the GDP contraction before VC money becomes as easy as it was for the last five years.
Easy money being available after five years is also uncertain. With covid shock, then global sanction following Russian invasion, and deglobalization following in the wake of these two events, global economy is faces serious uncertainty in coming years.
You don't say it explicitly, but there's a bit of a garden-of-eden in this story: Founders were running this great wonderful profitable business and then those darn VCs come in and ruin everything.
A founder isn't forced to take on investors. The same founders who were so "down to earth" and profitable are the ones making the decision to take on investors. The founders can't be responsible for profits and then suddenly get taken advantage of by investors. Everyone involved is eyes-wide-open.
Lots of great businesses have been built, in partnership with investors, during higher interest rate periods and downturns.
Disagree. These companies absolutely pump out cash on a free cash flow basis:
"It’s the absolute dollar free cash flow per share that you want to maximize, and if you can do that by lowering margins, we would do that. So if you could take the free cash flow, that’s something that investors can spend. Investors can’t spend percentage margins.” “What matters always is dollar margins: the actual dollar amount. Companies are valued not on their percentage margins, but on how many dollars they actually make, and a multiple of that.” “When forced to choose between optimizing the appearance of our GAAP accounting and maximizing the present value of future cash flows, we’ll take the cash flows.”"
Bingo. The VC wants the grand slam that returns the entire fund. He'd rather have an x% chance of a grand slam than a 3x% chance of a double/triple. Founders have a very different calculus because their risk isn't spread across a portfolio of companies.
The problem is that choosing to be unprofitable is a strategy that maybe worked (or just was fashionable) the past decade under very specific circumstances (lot of free money chasing higher returns in a context of very low rates), but otherwise obviously makes no sense, it's antithetic to the very idea of a business. It's not to be confused with the sane version that is reinvesting profits for growth instead of distributing them as dividends.
In the space Atlassian is in, choosing to be unprofitable while quickly growing could make sense.
It is not necessarily true for other sectors (e-scooters, different delivery services, maybe even Uber), as there is no stickiness in those areas. Whenever a cheaper Uber would come to my city, I'd drop them within a second. They are usually cheap while they can burn VC money.
If Atlassian can keep their system for a couple of years in a big, slow legacy company, the company will end up with tens of thousands of tickets and pages.
Then, no matter how everyone thinks that all the products of Atlassian is terrible (there is a thread about it every second month here), the company will never leave Atlassian because nobody wants to spend the time on migrating all that stuff and everybody is afraid to say that "we will probably not going to need poorly written user stories from three years ago", and they don't want to risk that the new system doesn't cover everything that e.g Jira does.
Once a company is locked in, it will keep paying because paying any amount is easier for them then migrating, training the employees to use the new system, broken links, missing features, etc.
You have it nailed: they offer low-churn products.
Atlassian is well-managed. Their revenue is fine. Their cash flow management is good. Their compensation plan is effective at retaining employees--the stock employees receive is likely to be more valuable at the end dof the vesting cycle than it is today.
Atlassian has got a collection of offerings that are industry standard. When used at large companies, they become quickly entrenched, with very low churn.
It is also a collection of offerings that is chosen by startups. Last quarter through a year from now, I expect that stream to be dry. But they are on 3-year contracts at an awful lot of got-my-Series A startups that will have to tighten their belts in other ways before trying to rotate off of Atlassian.
If you are actually producing e-scooters it could make sense as well when you have plans for reducing your costs long term through economy of scale so you reach the minimum efficient scale.
> but otherwise obviously makes no sense, it's antithetic to the very idea of a business.
How does it NOT make sense? The purpose of a business like this is not to generate some short term profit. These are winner-take-all markets - they're playing for complete and utter domination of an entire product category.
Their Q1 revenue grew 37% YoY - how on earth would you care about profit over what they doing here? They should keep hitting that as hard as they can.
Yep, exactly what UBER is doing and what Tesla has found themselves doing with high spending on their Texas and Berlin Gigafactories. It's a short term pain for domination... expand fast and be the market leader in every country before someone else beats you to it. Then, soak in the profits.
Which works when the unit economics are good. You can take the profit from an operating business, and just inject it back in the business to grow. That sometimes looks like an unprofitable business, but the test is: "if the company freezes growth tomorrow" would it be profitable?
Teslas are profitable, once you pay off the amortized cost of a factory. It isn't clear that uber is profitable. They had 5-10% gross margins pre-IPO, and it has gone negative since.
I think it can make sense temporarily trade profitability for growth, especially if you are using debt/funding to take advantage of certain circumstances. But it certainly isn't sustainable, and the purpose of the growth should be to increase profitability in the not too distant future.
You could rephrase "choosing to be unprofitable" as "spending revenue on more staff and/or higher salaries to retain them" for software businesses. Or in the case of Atlassian, acquisition.
> I'm paraphrasing here but he essentially said, you're leaving growth on the table. His thesis was growth is more important than profits.
But, you can't grow forever. At some point you hit things like the maximum market size and there's no longer any way to invest your profits back into growth.
Or, to hit a lot closer to home: As a stockholder, your stock won't appreciate in value forever. Software companies very rarely turn into Microsofts and Googles. You need to sell at some point in order to realize the value of your investment. (Unless you're getting dividends.)
> But, you can't grow forever. At some point you hit things like the maximum market size and there's no longer any way to invest your profits back into growth.
Atlassian is probably a fair bit away from that. Amazon is much closer to that mark today but they got there after following exactly this strategy since the 90s.
>> Atlassian is probably a fair bit away from that.
How do you justify that?
One way Atlassian's market size gets limited is by being viewed as a competitor to Microsoft (or other large incumbent's) products. Some customers can choose both, but not everyone can. The feature and experience differences don't matter much to the buyers (procurement), so if something is cheaper elsewhere, then it's a harder sell. It also increases risk in a potential recession where Atlassian is viewed as a luxury option. I feel like JetBrains play a smarter game here.
It feels like folks have forgotten how bad a niche developer tools have been. Circumstances have meant that VCs have been throwing money at developer tools and developer experience has been in vogue. Things will probably be better in this wave than previous ones, but it's still much riskier than other markets. Developers may rule the world, but the software powering their day-to-day is very different between software companies and the majority building line-of-business software.
Amazon is a bit of a unicorn in this regard though. They've been able to consistently pivot profits into expanding services into new (but highly related) areas. Most companies are overly aggressive in trying to chase exponential growth, they end up outgrowing their competence.
> When I worked there, they disclosed all financials in our internal Confluence site.
I worked at Rising Sun Pictures (RSP) in SA 2005–2007 and the CEO at the time, Didier Elzinga, did the same.
But what RSP did went even further. Didier and the CFO did a full disclosure presentation about the company's financials quarterly or bi-annually (can't remember).
It was great. Not least to make everyone understand why they couldn't pay rates that VFX professionals who moved to AUS from the East coast or London where used to – at least at that time (it was early years for RSP then).
RSP remains one of the best workplaces I ever had the luck to be employed at.
Afair Didier was also in some role on the board of Atlassian at the time. Maybe not a coincidence.
> it's actually bad to be profitable when you're growing
VCs love risk. They will want to dramatically reduce your chances of a small positive outcome if it means a increase on your (always small) chances of a huge positive outcome.
VCs love _technical_ risk. Outside of the very unusual circumstances of the Zero to One capital-funded-monopoly-theory era, they have considered _business_ risk quite toxic.
My point is that you state "VCs love risk" and I'm trying to help you clarify the way you think about this. VCs don't love _risk_ at all, they love _things that are an technical execution risk but would sell immediately if they can be done_.
Business risk stuff - does the market exist? is a new pricing model possible? etc. - is not at all on the list of risks that VCs like.
It's like that scene from Silicon Valley (which is almost always accurate).
Seriously, when did it become normal in capitalism that you should not prove that your business can make money? That there a customers willing to pay for your product? That the promise of future maybe profit sells better than actual profit now? This is insane.
We've been in a bubble so long that there were people who have worked only in the current tech bubble. People run companies now that think a stock market crashes ultimately means more money flows in from VCs. I once worked for a c-level that seriously thought he had discovered something amazing when he realized that a company that made more than it cost to run the business had unlimited runway... the very idea that a company could run without constantly running to investors begging for more cash was completely foreign to him.
This has been the consequence of increasingly cheap money and investor money having nowhere to go after the real estate crash in 2008. To be fair, if money is basically free then it does make sense to grow without worrying about a profit. If you've had an entire career without every having to worry about more investor money coming it, it would start to seem wasteful to not spend it all.
But that's why these current economic conditions have me very worried: money can't be cheap anymore. If interest rates continue to rise we'll see a massive contraction in tech. First it will be the smaller, direct to consumer startups, then it will be all of the companies that have those startups as a non-trivial portion of their revenue.
If I have a company with good cash flow, all employees (including me) are compensated well, and I'm spending a chunk of that cash flow on R&D and growth but have only marginal profits if any am I doing something wrong? Should I cut R&D to pay dividends? How about if the company is privately held?
There's a difference between 'not profitable' and 'losing money.'
If "profitable" is a switch you can flip, then what you're describing makes sense.
The issue is that many of these companies have never demonstrated that if they want to they can be profitable. The big assumption in these growth models is that there is a point where you can just magically flip that profit switch.
For example if I run a lemonade stand where I spend $3 to make a $1 glass of lemonade, even if I am able to use investor capital to keep growing my lemonade stand to be the only lemonade stand in town, or even the world, it's not clear that I can survive if I'm forced to make a profit.
I worked for a company that rented a new expensive floor in the heart of NYC to show "growth" to other investors. We were supposed to spread out for the optics, when potential investors did a walk-through.
Wild speculation has been a feature in capitalism for _centuries_. There are any number of interesting historical schemes to read about where investors lost their shirts, or, sometime won big! Every new business venture has risk that it will fail, even in "stable" industries. We should celebrate trying new business that might not work. We just need to ensure we don't socialize the losses.
> One thing that stood out was that he said, it's actually bad to be profitable when you're growing.
The only conclusion to this statement is "When we will stagnate we will then start making profits"
This doesn't sound like a great strategy to me. This is why I'm not investing in "no-profit but growth" except for the stock price increasing in the short term.
I think it depends on what you mean by "profitable".
If that means profits available to, e.g. pay dividends with then sure. But I think it ought to always be the goal to have a profitable operation then you can plough the profits back into the business to push growth (which will mean reporting 0 profits).
The character Russ Hanneman on the TV show “Silicon Valley” took it a step further stating that having no revenue to speak of makes a company more valuable. It’s satire…but is it?
It matters what portion of the cycle we are in. We used to be in the voting portion, now we are in the weighing machine portion and things are very different.
“In other words, the market is not a weighing machine, on which the value of each issue is recorded by an exact and impersonal mechanism, in accordance with its specific qualities. Rather should we say that the market is a voting machine, whereon countless individuals register choices which are the product partly of reason and partly of emotion.” -Security Analysis 1934
A company with no revenue can potentially raise at a higher valuation with a company of $1 of revenue - because now it’s real and investors will start making their mind up about the actual possiblities of the investment
Directly experienced this - having actual _profit_ makes it hard to encourage fantastical storytelling about how big the upside is. It's the company future equivalent of mark-to-market.
Revenue .. well, if you can get huge revenue with huge losses and convincingly demonstrate (mostly by spending) that more losses (= more capital) means more revenue can actually take you a long way. Almost all of the "unicorns" and "decacorns" embraced this model - lose $2-5 per $ of revenue but able to demonstrate almost unlimited market. Most of those companies can never, ever be profitable entities.
I've heard this time and time again in SV circles. It probably is for the right founder who is able to paint a rosy picture and a nice story. I'm not that kind of person, so it's bonkers to me.
Like Adam Nuemann. You have to be tall and loud. Doesn't matter if you are making sense or not. Sometimes VCs act like gullible women on a date who are enamored by a douchebag, I swear.
The article talks about this. The problem is that growth is not there.
What you're left is a company with 8000 employees and a system to problematic to change.
With the recession incoming, the time for free money is over and tech startups are bound for a correction. I'd sell or get ready to wait 10-20 years.
Even in the wait scenario, you're basically hoping that a huge corporation will transform itself and rediscover their startup roots - which is not likely to happen.
It happened with Mashape (sold their unprofitable marketplace to the RapidAPI people - geez, what a bad deal, it was painful to watch) and they managed to reinvent themselves with Kong.
They literally did a bunch of experiments and went on with what succeeded, ignoring their main, flawed, business model.
That's what companies should do to chase success, they need to act like venture incubator, don't bother their teams with corporate BS and hope one of their teams will succeed. If they behave like mammoth corporations they're doomed to fail.
And their typical customers are the least exposed to recessions i.e. medium to large companies who are making software purchasing decisions for the long term.
Atlassian isn't a US company, and if the US is going to have a recession (which I think is doubtful), Australia certainly has a good record on avoiding them.
Atlassian's largest source of income is almost certainly the US.
And even if Australia is unaffected by an American recession, much of Europe, and much of Asia won't be (especially with China's growth slowing down).
Which brings me to my second point, which is the only reason Australia was able to avoid a US recession was selling itself to China, something which it is politically unlikely to do so anymore (although I'm not up to date on the new PM's China policy) and anyways, China may not have the capacity or willingness to support Australia anymore.
Australia recessions are uncorrelated with US due to mining and other raw materials exports being a huge share of their economy... especially selling those materials to China.
I doubt miners are big Jira users.
US tech companies who are cratering right now though...
Yes but with the chance at a job-for-life guarantee and possibly months off per year.
My wife & I have a couple academic friends and they make 1/4 our income probably, but they are unfireable & they also just took off for another 6 weeks stay in southern Europe at a family home this summer .. so there's that.
Guaranteed income & time flexibility are hard to measure in absolute dollars.
My wife & I are on the other hand on our 5th/6th job in our almost 20 year careers, never having had more than 2.5 weeks off consecutively. The hustle now is maximizing the dollars and building some alternative income streams so we can start to wind down the intensity in maybe 10 years and fully exit workforce in 20 years?
A few days ago[0] I was writing a Jira ticket after hitting the "Create" button and I wrote the description (the body of the ticket) for ~30 minutes. I switched the ticket type from A to B (no epics involved) and it wiped out the entire description. All I did was select a different item in a select drop down box provided by the form's UI.
There was no warning it would clear the description and no draft saved. I lost 30 minutes of work.
I normally manually copy textareas every few minutes on any Atlassian page because I don't trust their site (to be fair I do this for most sites too) but in the above case I had just copied a link reference which overwrote my clipboard. At the time I also didn't have a multi-clipboard tool installed since it was using a company issued machine that I don't have tricked out yet.
I never write anything in any web interface. I write in notepad and copy and paste. I had many bad surprises ... I can't trust web interfaces.
And I use the Windows clipboard manager too.
I also prefer to write my stuff offline and than paste it to a web interface. That works great, until you write markdown and paste in into Confluence.
Instead of just accepting markdown and formatting it in the same way it does when you type markdown, Confluence puts it between code tags..
Jira does this better, but is still weird with their text formatting. There are two different kinds of input fields, one of them accepts markdown, the other one some other kind of markup language. Copying some formatted text from one of the inputs to the other doesn't work because of this.
> That works great, until you write markdown and paste in into Confluence. Instead of just accepting markdown and formatting it in the same way it does when you type markdown, Confluence puts it between code tags..
If you are in the new editor for Confluence Cloud (i.e. the editor based on ProseMirror rather than TinyMCE), you can sometimes get it to do "the right thing" of converting pasted markdown to formatted text by copying from a different text editor. For example, for me copying from windows notepad always does the right thing, but copying from vscode doesn't.
It had never happened to me except for Confluence and Microsoft Teams. Firefox even preserves the typed text between reloads of the page - so unless the web app hacks the textarea somehow, the text will stay there.
You mean literally Windows' Notepad? Because that's about the worst app to write on. Not even going to go into how it's almost devoid of useful commands.
Make one mistake, you're good. Make two, tough luck, you can only undo once. Accidentally select some (or all) text and type over it then somewhere else? Today's really not your day. It's actually worse than textboxes in this respect.
This happened to me more times than I'd like to admit before I knew better.
>You mean literally Windows' Notepad? Because that's about the worst app to write on.
It's actually one of the best on Windows, because if you leave your computer for a moment and it randomly decides to restart to install a Windows Update, often a notepad with unsaved changes will block it from restarting, whilst unsaved work elsewhere won't.
Vs Notepad++ that simply autosaves in that case?
Only problem there is when you realise you have 50 tabs of scratch data you were expecting to have been discarded by now but are all still loaded up next time it starts up...
I think he considers notepad.exe one of the best applications expressly because it stops Windows from restarting when he doesn't want Windows restarted, which, ironically, it presumably wouldn't do it if had Notepad++'s better-designed and usually preferable behavior. (The Notepad+Windows case seems like botches (individually user-hostile forced reboots and poor handling of state on restart for Windows and Notepad respectively) partially cancelling each other out.)
Atlassian’s WYSIWYG editors are some of the buggiest bits of UI I’ve ever had the misfortune of using. Writing anything in Jira or Confluence is an exercise in misery. Even basic stuff like hyperlinks often go wrong.
I somewhat agree. For me the pain point is that confluence randomly loses the connection with the editor.
As far as confluence, or just about every web tool I've used that has text areas (slack, etc) - I really wish that would be handled over to the browser.
The problem with JIRA is that yes, everyone uses it, but most people hate it. In my experience, the only people that advocate for it are PM/PMO/TPM type people who need very specific and customizable workflows and reports. And even then, they continually run into quirks and bad UX everywhere.
This leaves them very vulnerable to another company taking their market share, as soon as they create something better that is extensible enough to get management signoff. I know a lot of companies have tried and failed here, but someone's going to eventually do it.
I can understand your frustration, and there should be some warning, but this is not a bug.
Every issue type is configured with its associated issue-create screen and that screen has its fields. When you change the issue type during issue creation you're replacing one set of fields with another which results in the information loss you experienced. This just doesn't affect the description field, but all other system fields and custom fields.
I guess you don't use Windows but in case you do, you should use clipboard history. Just press Win+V and enable it, then press that combination again anytime you want something from the history, and a UI opens up with your last copied things. It supports schreenshots too.
Sounds like an opportunity to create a chrome add-on that can save any field data. I believe most session managers do that but if the field is wiped out, so is the cache.
Just a thought, but a lot of Jira installs often have wacky addons and such. Maybe one of them created an undesirable interaction with Jira that caused this. Is that a reliably reproducible bug? Maybe something with how your team configured the other issue types? Very annoying bug regardless.
Is there an openish source piece of similar software ?
Jira cops a lot of hate on HN, but really to paraphrase Churchill on Democracy - "Jira is the worst issue tracking software, except for all the others".
Linear.app is awesome. We switched from Jira and our team's participation on issues went through the roof. It's fast, clean, has keyboard shortcuts and replaces agile terminology with simpler, familiar paradigms. We activated Slack, Sentry and GitLab integrations too. It's a beautiful piece of software to use and part of the reason we chose it was to inspire ourselves to try build something of similar quality in our own domain. Seriously, it's that good.
I've also used Redmine a few years ago. It gets the job done but nowhere near as slick and fun to use.
I hate how the elegant simplicity behind the agile development principles was so thoroughly co-opted by scrum, so now when people think “agile” they actually mean scrum but have no idea that’s what’s happening.
I hate how when people say scrum they really mean something which is not well defined and you end up with some weird system that only some "scrum master" understands and that they seem to be making up as they go along.
Scrum is mostly defined. The problem with scrum is that while agile (in general, not only software dev) is a methodology (a set of practices and tools) to be applied in a particular context, scrum takes those agile methods, packages into a behemoth with a very particular workflow and sells that instead of typical "consulting" - deployment of tools to control the process.
In practice scrum is extremely unagile, because there is one very particular workflow to be used and actual workflows have to be adapted to suit scrum. Sometimes it leads to increased agility, but more often than not it does not.
Probably the central piece of scrum are sprints. Nothing wrong with sprints in general, but sprints rely on feature sizes being sprint-sized. Sprints only work when you actually finish planned stuff over the course of a sprint. Naturally, feature and especially release sizes vary. By focusing on milestones one can actually plan and schedule work and releases. This is agile - you can shuffle stuff around. Instead scrum tries to sell fixed size sprints to give impression of steady movement forward, but this decouples sprints from milestones and slightly counter-intuitively reduces agility - shuffling milestones around sprints merely gives you a bunch of unfinished milestones, but also a bunch of finished sprints. But variable sized sprints based on milestones sound too much waterfall-y when the selling point is departure from waterfall.
Interestingly this attempt to squeeze features into sprint-sized chunks is one of the reasons for technical debt that you then must somehow manage, simply because squeezing features comes at a cost of technical debt. There are more reasons for technical debt, but it is slightly humorous when a tool aimed at managing/reducing technical debt introduces debts of its own.
A bit tangential to scrum, but Facebook's story of Hack/HHVM is well-known story somewhat indicative of this. When you size features according to wall-clock sized release cadence (instead of sizing release cadence according to feature sizes) you inevitably accumulate technical debt - new features should build on top of past features, but deficiencies in past features prevent new features from being built on. There are more or less 3 ways this plays out: 1. actual feature release cadence drops due to increased development weight; 2. release cadence drops due to fixup "features" being released; 3. release cadence drops due to dedicated to fixing. Do not get me wrong, technical debt accumulates and impacts release cadence any way, but with feature sized sprints this does not come out of nowhere.
Over the years teams (usually informally) understood deficiencies of scrum process and started throwing pieces of the process away, shuffling them around and having weird mess of system. This is not due to scrum not being well defined, but rather scrum being a hammer in search of nails.
Agile methodologies generally came out of manufacturing - process based workflow. Scrum takes those practices and packages them as a project management tooling. The whole point of agility in processes is the ability to adapt in the middle of the process. Project management, on the other hand, needs plannability and progress tracking. There are weird intersections between the two and IMO scrum fails to satisfy both - neither it is good at adapting mid cycle (because scrum checkpoints mid-feature), nor is it good at future plannability (because it focuses on short term goals). I have seen scrum get distorted in two major ways: either "sprints" get stretched into months long waterfalls, or sprints mostly reshuffling priorities in "in progress" pile and checkpointing progress.
Then cite the definition? If you will cite the https://scrumguides.org/ - I have yet to work in any team that uses scrum that follows this even slightly.
GitLab issues are better for all but very large projects. Jira will win on features, of course, but unless you have 50+ people working on the same thing, multiple dedicated PMs, etc. you’re almost certainly not seeing enough value to be worth the frictional cost and temptation to divert time away from the product to build Potemkin project plans in Jira.
(This is the same failure mode as many Agile-as-practiced projects have: once the incentive structure is decoupled from results, someone will have a full time job moving tickets around in a way which is considered productive even if the project is foundering.)
You have fewer problems with Jira. You’re still paying more for a slower application with a clumsy UI.
I also wouldn’t be so quick to condemn the PM. I’ve seen plenty of developers insist on complex workflows and custom fields because they think they can automate everything, only later to realize they’ve created a second job. The problem is basically the lack of a functioning feedback mechanism to ask “do we need this enough to pay for its care and feeding?”, and I’ve seen people from every role on either side of that, although it’s certainly more common to see business people underestimate the complexity of what they’re asking for.
> it’s certainly more common to see business people underestimate the complexity of what they’re asking for
I think this is a factor of their days being filled with busywork (from my perspective), so naturally the dev should have time enough to do all that during the day as well. The people asking you to fill out all those fields are not the ones actually doing so (or their entire job is filling them out).
It depends on how you define "better". I'd say that anything else I used (github/gitlab issues, asana, trello, even a spreadsheet) works better *for me* - i.e. it is faster and easier to find things in a small team. I only add things or focus on one issue and then remove it. I still don't understand why mid managers love it, but I guess they have different use cases than me...
I know, but it was usable when I last used it. (and it was not designed by Atlassian AFAIK... and even if it would, I don't have anything against Atlassian except that they make really terrible software which I was quazi-forced to use)
I used Shortcut (formerly Clubhouse) for a while. It was a huge breath of fresh air coming from Jira. But I'm not sure how much of that was that I despised Jira more-so than I loved Clubhouse.
I started using Linear recently and I can never go back to Jira. Linear is that good.
My main annoyances with the Atlassian suite are mostly the bugs: for example, they have 3 different parsers for their wiki markup which aren’t fully compatible, and none of them are as good as Markdown. They’ve had years to do QA but…
The only thing I see in Jira as an actual gap is the inexplicable lack of a standard view for showing all of the tickets in a particular sprint. You can make custom queries, of course, but it’s such a common need which everyone else on the market solved in 1.0.
I've tried YouTrack from JetBrains, and I've found its UX quite bad. I've used Asana, Trello, Microsoft (they had/have a tool for project management), Github Project. None of them seemed to work as well as Jira. (My opinion).
Microsoft's project management tool is Azure Dev Ops (used to be called Visual Studio Team Services), I found it pretty comparable to JIRA for the most part.
I used Azure Dev Ops at my last job! I thought it was fine – though I think some aspects of it weren't intuitive (maybe an unsolvable problem for a PM tool). Our team standups occasionally included someone discovering a useful Dev Ops feature that was simply hidden too well.
But the tool felt fairly fast and did it's core job pretty well.
Anyone know why they called it that though? Much of its key functionality has nothing specifically to do with DevOps, and I somewhat doubt it really supports everything DevOps (in an Azure world) requires...
I remember that Jira had a kanban board or something like that. It was almost 10 years ago. If it still exists and you're using it, give a try to Kanbanize. It's something that I almost really liked to use. The team bootstrap was done by a guy that really knew it well and kept managing and coaching for months. No idea what it would look like to start using it from scratch.
Considering the amount of money you pay to have it, "it works" is not even the bare minimum. Lot of things work.
The problem with Jira is the total disregard for UX. Very simple tasks like moving tickets out of a story take way too many steps when it should take one click.
They don't seem to want to improve it because of legacy customer or reasons....
The functionality of Jira is great because it's basically turing complete at this point. A dedicated enough force of middle managers can warp it however they want to.
In the worst case sure. It also lets a small team start easily and modify it as they grow.
In many ways it's like Excel. Everyone says making an Excel killer should be easy because people only use 10 features. Problem is, everyone is using a different 10 features.
As another comment rightly pointed out, Atlassian has some recession "insurance," because JIRA tends to be bought by big, slow companies. Big, slow companies implement JIRA with the same agility and cleverness as they do their AD implementation, which is to say: it tends to be a nightmare of permission complexity caused by internal political machinations. That winds up making the UI slow and clunky, and driving the end users crazy.
I'm using Jira, too, and I don't think its slow. It actually works quite well and has loading animations for longer tasks, so it never feels laggy. Sure, it's not vi-levels of navigation speed, but it never bothered me. The UX works for me, too (although it took me a bit to learn it, to be fair).
Linear & Shortcut are both significantly better. Linear isn't even in the same realm as Jira in quality and productivity; its like comparing Excel to Jira, yeah you can make Excel work but you'd be out of your mind to use it for something like project management. Similarly, with the advent of Linear; you'd be out of your mind to greenfield on Jira. Why not spin up OracleSQL and write your app in C++ while you're at it?
Gitlab & Github issues is also pretty solid. Lightweight, but it works for what it does.
Asana is another decent competitor, though I don't tend to recommend them for project management. Its there though.
I've organized some small software teams using Notion. Its surprisingly functional. The big downside is the lack of universal structure or a decent API to even build your own analytics against; great for the ICs, but not great for managers.
There are lots of alternatives out there looking for marksetshare. I've not personally used ClickUp but it looks fantastic just from their screenshots: https://clickup.com/features
ClickUp is a confusing mess. It tries to be the centre of your universe without doing anything particularly well. It copies features verbatim from other software and then slams it in as a new "view". The coding doesn't seem to be up to scratch either, e.g., updating a value won't always update it everywhere it's displayed. It's very hit-and-miss.
I had a look at Asana again for non-software project management after dismissing it 8 years ago when trying to use it, and was pleasantly surprised: it's much more opinionated than it used to be, a lot slicker, and it integrates with everything I use.
I also use Linear for software development, and won't ever look back.
I agree.
We used ClickUp at my old work, and I felt like I was the only person who found it extremely unintuitive and confusing. It was about the 5th project management app they switched to, and the worst for me by far. Unfortunately they stuck with it until I left.
ClickUp is the first piece of software to confuse me before I even used it.
Their intentionally obtuse marketing all over NYC would drive me insane. Then one day I had a natural reason to stumble upon it, it was had literally nothing to do with what the advertising implied, and the interface was so deeply overwhelming that I wouldn't wish it on my worst enemy.
Like an almost anxiety inducing level of overload from the moment I tried to use it.
Maybe it's great if you live in GANTT Chart Burndown Land, but generally you want something that everyone can use, not just your PMs.
Something that gets "close enough", like Mattermost/Rocket.Chat can get to Slack? Probably nothing, given how huge the surface attempt for Jira is.
But for project management and issue tracking in general, there are quite a few alternatives:
- OpenProject: https://www.openproject.org/ mentioning this first, because it's what I use for my personal needs and feels pretty decent (issue tracking, time tracking, references, comments, files, Wiki, cost reports and so on), though is definitely not nearly as popular
- Redmine: https://www.redmine.org/ is probably also a really good alternative to mention, while the original UI is dated a while ago there was a project to create something more modern and most of the times when someone is using an alternative to Jira, I've seen it be Redmine in particular
- Odoo: https://www.odoo.com/ is a more modular system that I haven't really used much personally, but have heard about being talked at the occasional conference in my country, the idea seems nice at least
Also, there are probably a few more lightweight and Trello-like systems for Kanban boards:
- Nextcloud: also has some apps, like https://apps.nextcloud.com/apps/tasks and https://apps.nextcloud.com/apps/deck that, while basic, can be really easy to get started with if you already have Nextcloud
- Kanboard: https://kanboard.org/ is perhaps the best Kanban board that I have personally used, just because of how snappy and lightweight it is (at the expense of the features it has, admittedly)
I've also heard of projects like Taiga and Wekan, though can't comment on those due to limited familiarity.
Oh, I also probably should mention GitLab, which has lots of project management features built right into it nowadays, as well as stuff as release management and whatnot: https://about.gitlab.com/features/?stage=plan
We use GitLab internally. It has plenty of project management features these days and just seems to work for us. The team universally dislikes Jira and adopted GitLab instead.
Tbh, most of big enterprise software UI just plain sucks. I see this as a natural consequence of being too packed with features, to target the widest audience possible.
Best software UX is made by smaller teams that dedicate themselves to solving one problem for a very specific niche. And once they grow, it all inevitably turns to sh*t. C'est la vie..
A company I worked for before used Redmine. It was easy to use, had a great API and was quite fast. Open source as well, unless you wanted to pay for a custom installation, which went by the name of EasyRedmine.
I use Linear these days, and that's great too. But for a small company? I'd recommend Redmine.
We tried to implement it 3 times and performance was horrid. Bad enough to have us give up and move to a different platform. I have not used Clubhouse or Shortcut.
One equivalent that does everything and is as flexible as jira, I don't know.
There are however a multitude of software that provide some of the functionnalites or can do many things jira does but in a more opinionated way.
It depends if one's company want a tool flexible enough to suit gazillons of different workflows with integration with many other tools or not. If the goal is only to have issues and kanban boards I think there are many alternatives.
Funny thing is jira is such a mess Atlassian introduced jira service desk more focused on tickets while the former can also do that.
> Funny thing is jira is such a mess Atlassian introduced jira service desk more focused on tickets while the former can also do that.
Not quite. Service Desk (aka Service Management today) has a number of capabilities that differ quite significantly from Jira Software. The most obvious is the end-user facing help portal. But how users are managed is quite different, it has SLAs, different reporting, a knowledge base, etc. Just like Jira Software is flexible but tailored to software teams with boards, backlogs and sprints, Jira Service Management is tailored to IT teams and requirements specific to that market.
One equivalent that does everything and is as flexible as jira, I don't know.
There are however a multitude of software that provide some of the functionnalites or can do many things jira does but in a more opinionated way.
It depends if one's company want a tool flexible enough to suit gazillons of different workflows with integration with many other tools or not. If the goal is only to have tickets and kanban boards I think there are many alternatives.
Why does a competitor need to be open source? ClickUp, Asana, and Shortcut/Clubhouse are all competing in this space. I consider Jira to be far and away the worst one of that bunch, but beauty is always in the eye of the beholder.
My personal preference is ClickUp or Asana as they offer flexibility to bolt on routine task management in a much more flexible way.
A competitor probably shouldn't be. The only people who need a competitor to Jira are large companies who have a budget. There are lots of small companies and open source companies, but they have no need for the complexities of Jira and should avoid it.
Recently found out about ClickUp. It's not quite as feature-rich as JIRA, but nowhere near as simplistic as Trello, and its fairly jank-free so I'm a fan.
Not in my experience, at least not enough of an impact to make me really care. Azure DevOps was far worse in my experience, and many of the ones SW Devs promote can't roll up to the portfolio level which is where the strategic and purchasing decisions are made.
Featurewise, Taiga is the closest competitor. The only missing bit is mobile apps and real-time notification. Other than that, there's almost nothing that Taiga doesn't do.
Author writes that Atlassian has no network effects. That is BS.
Atlassian has massive network in its ecosystem. There are Jira Consultancies, 3rd party apps and plugins and deep integration into customers processes. If one element grows the whole ecosystem profits.
Secondly, Atlassian is not a bad company just because it's stock is overpriced. It might be a bad investment!
Over the short and midterm Atlassian is in some trouble because it has problems to scale the development while shifting from legacy to cloud. They will solve it. Still i expect some bad news to come.
These bad news will beat down the stock and maybe create an opportunity to buy a great company at a great price.
PS: The Atlassian invoice of my employer tripled over 1 year. You start cheap and simple and with every plugin and product you add the invoice grows. Thus to value Atlassian you have to look into revenue per customer over its life time, which is far greater than this year's revenue of the customer.
I think you might be confusing upselling and cross selling with network effects. Upsell is when you convince a customer to purchase additional service, like offering different tiers of subscriptions. Cross selling is where you sell adjacent services related to (and that possibly integrate with) the original service.
Network effects are where the direct value of a product grows simply because the number of users increases, causing the network itself to grow. The classic example are social networks. The more people on your social network, the more people are likely to join your network and less likely to join a smaller competitor. I am not sure there is anything in Atlassian’s product offering that quite fits that description, but that isn’t to say there isn’t plenty of upsell and cross sell opportunity as you describe.
I disagree. A network effect does not need to be inherent to the product / service itself. It can originate from other sources. What is the network effect of eBay? As a seller I do not care how many other sellers are there. But I care how many buyers are there. For a buyer it's the reverse. Buyers attract sellers and vice versa. That's a network effect too. For Atlassian it's similar. Jira customer attract Jira consultants and vice versa.
Ecosystem is the better word for sure. it's competitive advantage is still a network effect.
Jira is an interesting product everyone loves to hate.
It has the do-whatever-you-want configurability to fit anyones SDLC. Really its a software product that allows you to mirror your organizational structure.
That said, 99% of software projects I have been on could be managed with a simple Kanban board like Trello (which they now own).
Unless your firm has staff who are full time Jira jockeys in the form of project managers, you'll never be able to leverage the more complicated workflows/linkages/planning features.
It's kind of amusing: I've seen a few times developers rebelling and moving to whatever other random tool (Atlassian's own Trello, Pivotal Tracker, Github's thing, stickers on the wall) as soon as a hardline PO/PM left the job. Only for JIRA to return when another PO/PM that "really really needs the reporting features" (but didn't really use them) was hired.
heh, I was once on a dev team that some how got moved into the project management section of a company. The thought was we'd help out and fix the little stuff that the PMs needed done that they couldn't get other teams to prioritize.
Obviously a bonkers idea, but they went for it. It was just jira all the way down. They wanted us to create separate tracking jiras for pages, before we worked the issue in the middle of the night. Nobody was actually doing anything, especially the devs I lasted a couple months before I moved. At the end of the year, everyone that stayed got promoted a level as a dev. I went back though git and couldn't find a single commit from any of them. Just bananas, they all got promoted to a higher level as devs for busy work, but jiras don't lie, right?
My fave thing about Jira is how between the tool & it's plugins, you can roll up all sorts of views for management reporting purposes.
Despite this, exactly zero shops I have worked do management believe their managers will understand those views.
Therefore at a weekly/monthly/quarterly cadence, "someone" (dev leads) have to spend hours hand updating some horrific excel view of project statuses for big management to understand.
All I really see managers using is the burnup or burndown chart. They seem to choose between up/down based on their current mood. But it doesn't matter which one they choose, it always seem to bring everyone's mood down anyway.
And yet when you ask if we can change from JIRA to something else they say "but my reporting".
Twice now I've worked at places that used Jira, and all it takes is one corner of the company to leverage it for some random oddball purpose to make it painfully slow.
One place started using it for managing thousands of assets, and eventually they were paying contractors tens of thousands to optimize their JIRA instance and untangle the mess.
Same thing is happening at my current company, where even in the last few months it's gotten painfully slower.
Wow. I had erased this from my memory, but: in a company I worked previously, every single string that had to be localised had to go into a JIRA task, after going into an internal localisation tool. Eventually they needed a separate JIRA instance with different logins because there were hundreds of new "strings" being created daily, some of those coming from user content.
> Therefore at a weekly/monthly/quarterly cadence, "someone" (dev leads) have to spend hours hand updating some horrific excel view of project statuses for big management to understand.
You're spot on about that. I've been the "someone" dev lead doing this so often I decided that someone should build a system that does this. You can see my progress so far at fixed.pm
Why is it always on the Dev team to completely uplift whatever is working for them, and never that the PM/PO/DPO/Scrumwhatever has to do the heavy lifting themselves? Is it because they would actually have to do work instead of just attending meetings, slacking other people for updates, and sending out progress reports? (Sorry to all you good PMs out there, I am talking about the median case)
If you are a PM and you come on a team that isn't using JIRA, and you want JIRA with all it's fancy bells and whistles, that's fine. Set up a board yourself, write all the tickets, capture all the work that's happening based on the dev's tool they are currently using, and update all the knobs and buttons to your heart's content.
My guess is the infatuation with JIRA would quickly diminish if this was so.
One of the best PMs I have had used to be a dev. The company we were working with used a terrible Jira like piece of software I don't remember the name of, but he had the devs just use Trello. He would go through and update the other thing for stakeholders. Worked great
JIRA is the case of a product made for buyers/deciders rather than for final users, like the dreaded enterprise ERP.
Atlassian's Product Managers believe their product is mostly used by other product managers, but they're dead wrong. Not that it matters, anyway. Atlassian could probably fire all PMs tomorrow and it would be the same, as long as the software ticks all the necessary boxes it will still sell the same. Just hire more marketing, sales and evangelists.
> full time Jira jockeys in the form of project managers
I find that a funny description because I've worked with many many different full time project managers who always took the view that putting data in Jira or equivalents and pulling reports before the project meetings were entirely a technician's job.
This stuff blows my mind but tends to occur everywhere
What is the value add of an engineer doing project management work in an environment where project managers exist
Should the project managers need to do a little coding then?
Also the quiet part out loud - project managers tend to be vastly cheaper (often 2:1) than engineers. Any and every task that an engineering team can offload to a project manager is big dollars saved by the firm.
I frequently find myself in engineering roles where I am doing most stakeholder comms, requirements gathering, JIRA ticket entry/management, project planning, user documentation, support runbooks, PR reviewing, a bit of dev, occasionally testing, deployments, and sit on the support escalation pager rotation. Any of the above tasks you can offload to a non-engineer saves the firm money.
Jira almost has too many hierarchy options / flexibility.
Epics, Milestones, Initiatives.
No two firms, and often within a firm.. no two teams has a similar definition / system in how they are used.
My last manager it was like a sniff test / definition of art thing. Constant arguments about epics being too granular or not granular enough. Bumping tickets up or down the hierarchy was hell and lead to many many hours of wasted efforts.
I suspect the following is built into valuations of many software companies with subscription revenue models: they can reduce headcount dramatically and keep a relatively tiny headcount of staff around to sustain the existing recurring revenue and be highly profitable even in a slowing economy. For example how many people would MongoDB, with close to a billion dollars of annual revenue, need to keep the lights on, assuming zero new feature development, sales or marketing? The software is already sold and integral to the enterprise projects that use it, and in the enterprise migration to a new vendor is often a considerable project in itself.
I think this is not as straightforward as you make it sound.
1. Often the way companies are structured requires specific teams and processes to exist and unwinding that is not easy.
2. It can be very hard to identify which people are actually critical. If you get it wrong it’s a big problem.
3. Additionally, firing a large percentage of employees will create a very negative feeling in the remainder so they might leave as well or their work quality will suffer.
4. Customers may lose faith in the business as a result and switch. Something like Atlassian has many competitors.
Are there any specific examples of this being done successfully?
I've worked (as in actively worked) in a couple restructuring efforts, and it went fine, but it wasn't on tech, it was on education. It went massively well. The universities were financially healthier afterwards, and all the remaining employees had safer (union!) jobs.
The trick for this being successful is most of the time by challenging the processes themselves, rather than the employees. Employees aren't useless, but process are. The reason you need 500 people rather than 250 or 100 or 50 to do something might be simply because you said so somewhere or sometime.
So, companies should review and change processes BEFORE reducing headcount. But alas, companies don't ever do it, because it requires introspection, egolessness and actual work, the sorta stuff that is rare in upper management.
> because it requires introspection, egolessness and actual work, the sorta stuff that is rare in upper management
It also may reduce the need for middle and upper management.
In fact, if you give people some confidence that they won't be fire and instead you will use their work on some more valuable action, ICs will line up on your door with ideas on how to cut their processes. But management won't.
Exactly. In the two restructurings I worked there were lots of people that everyone knew were fundamental to the workings of the institutions. Those people were confident they would stay, and ended up getting amazing raises afterwards so they could continue. Most of the complaints were from teachers who were there for years but were still working only 4-8 hours week, or people that had purely bureaucratic functions.
Amusingly, the best "firing" in one of those was the Dean of the University that had a seven-figure salary. The board replaced him with an administrator and with someone else from the faculty, and both were more qualified, but costed 1/10 of the price (still a huge raise for them).
AirBNB? They were flailing at the beginning of covid, taking a massive 2 billion loan at 10% APR to maintain cash flow. They laid off a substantial portion of their workforce, hunkered down, and it paid off - they went on to successfully IPO a year later, still in the pandemic.
The thing is, a high growth company like MongoDB doesn't need to fire a single engineer to turn highly profitable. They grew revenue 57% YoY last quarter and spent 52.6% of revenue on sales & marketing.
I just don't see companies being able to justify subscription revenue models in the coming downturn. Many opt to acquire software for a fixed price if they are financially sound, those who cannot, aren't going to be able to keep paying subscription fees methinks, i could be wrong.
Wouldn’t companies switch to a one time purchase or open source model if mongo stopped developing new features? Why would they continue paying a subscription for a product that doesn’t improve when money is tight? Especially when there are plenty of mongo competitors.
> Atlassian has somehow become the Benjamin Button of the tech sector — profitable as a startup and loss making as it has matured.
They where profitable, they didn’t need funding the only funding they took was for staff to sell some of the equity.
Them now making a loss I think is more a deliberate choice, not a business failure. They could of continued as they where making $$$ but instead choose to go from 700 people at ipo to near 7k today for pretty much the same product suite.
Those 7k people have to be working on a lot of stuff behind the scenes, building on existing products and maybe yet to be released products. Atlassian always said they where big on long term investment. I’m sure they could be profitable if they wanted but then would need to massively cut the long term investment.
I’m not to worried about Atlassian. Every large org I worked at is run off Jira. I do regret not selling a small parcel of TEAM at the end of last year though when it was over $440usd a share
> Them now making a loss I think is more a deliberate choice, not a business failure. They could of continued as they where making $$$ but instead choose to go from 700 people at ipo to near 7k today for pretty much the same product suite.
But this is exactly the kind of thing that makes a market analyst yell "FIRE!" during a bear market. Nobody trading stocks is going to look at a 10x headcount increase without meaningful additions to the product offering as a good thing.
The product suite differs significantly from 2015. Put aside new and acquired products like Trello and OpsGenie, the existing products have significantly expanded their capabilities and added Premium and Enterprise tiers.
Revenue in 2015 was $320M,
In 2021 it was $2B. That kind of growth requires growth in Supporting functions and infrastructure teams, not just in product.
They IPO'd 7 years ago, which looks even worse. They've had all this time and hired all of these people and largely kept the same product offering with no obvious improvements to performance or stability. Again, that's a market analyst's nightmare.
> While it is still used by many tech businesses (including the author’s), it has no real network effect — that is, users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).
Lol. At some companies, Jira workflows literally run the whole company. At my prev job, prod deployments were tightly linked to Jira.
The thought of running a 10,000+ development team using Basecamp is hilarious in its insanity.
Because that is where Jira primarily plays. In enterprise companies where it's rolled out across the organisation with tentacles firmly embedded into almost every process and system.
And whilst people continue to criticise Jira it continues to grow because in reality it competes with products like Rally not Asana. And there really isn't anything out there that can offer the same level of customisability and flexibility.
That should be the usual environment for Jira. However the only company I saw using it was a two people company with less than a dozen of consultants. That was in the early '10s. I was definitely not impressed by the UX, inconsistent, slow, apparently designed to make it hard to learn. Other companies I worked with later on (no more than a couple of dozen of people) use Kanbanize, Asana, TeamCity + YouTrack and yes, also Basecamp. On the development side, anything among GitHub (but no Actions yet), Bitbucket (plus Pipelines), Travis and custom stuff with a fair dose of Good Luck /s.
Indeed Jira scales a lot (although being slow) and is well customisable and flexible. Its plugin system is also great (although a better documentation of how to develop/maintain one, and of their APIs would grealy help).
But in the meantime, it requires increasing discipline and regular revampings of internal processes across dev, product, market teams, and that's a lot of energy to burn to make it "work" across an org.
Even more when you have people that are for very strict and precise adherence to processes.
Whereas a less flexible, good enough system could help funnel the same energy towards something more productive than just internal compliance for the sake of it.
You simply can't force one way of working on larger companies even if that way is undisputedly the right way. Because a lot of people will need to sign off on which tool to purchase and each of them are special geniuses with their own special genius way of working.
I'm not opposing a single Jira methodology to a myriad of other ones (tools or processes).
I'm saying that Jira, without being constantly challenged for what it is[1] creates its own growing and tiring bureaucracy because companies (even large ones) cannot agree on a right way to work (but will add piles over piles of bureaucracy).
[1] exactly like what Agile methodologies, or some certifications are; where now it feels like almost no one remembers/knows how to organize teams _without_ resorting to anything that Agile-thinking has tainted.
It somehow relates to the fact that, in some companies, more energy and money is burnt over how to organize the work rather than doing the work itself. And it definitely shows.
For real, I don't think it's all about "each special snowflake's way of working" but there are legitimate needs that change
Each team can have a different workflow with Jira
Jira works for non-software-development tasks as well
I've seen it used on companies having 4/5 levels of stories deep (think Initiatives/Epic/Stories/Subtasks/etc. Different companies split this different ways.
The plugins sound inconsequential but they are very useful (almost a must) in several occasions.
Thats the rub too. Jira setup in a simple way is what most people need. Yet you get process people in there and suddenly you have 50+ fields to fill out before you can even start working on something. Then another 20+ fields to fill out to close out a ticket. I went from taking 2-3 hours total to plan out a sprint, to it taking 3-4 days and many meetings. And noone can tell me how these fields are used day to day, what are they trying to solve, and how it was better than what we had. If I wanted to do waterfall I would not be having 2 week sprints and this process would be wildly different.
My (cynical) experience is that those fields are simply there to generate arbitrary metrics for the process people to show to higher-ups to demonstrate that they are “managing” the project.
Feudal-like political jockeying for power produces this nonsense. I've been beleaguered with such nonsense for most of my 28-year career, working in 3 Fortune 250's. It certainly doesn't help that JIRA is designed to be flexible enough to be all things to all people for all purposes. And that's why CIO's love to buy it.
Is there a breakout of company size vs revenue for Jira? Because for the past 10 years I've worked only on smaller companies and they all, no exceptions, used Jira as well.
> other than the initial hassle of switching to a new system
Is like saying: "people can move overseas with minimal cost (other than shitloads of migration bureaucracy, frequent flying to meet family, put their entire furniture on top of a cargo ship)
More like trying to remove an invasive cancer that has spread to all parts of your body whilst you're still needing to move around, be productive and live your life.
I'd say that for many large companies, Jira is better than the alterntive of having multiple systems that need to be kept in sync. Steering any large company will be a mess, no software will ever make that easy. And any software designed to be that flexible will end up being slow eventually.
While it is true that Jira is "sticky", the statement was that it did not have a network effect.
MS Word, Facebook, WhatsApp, Visa, they all have network effects: every user you add makes your product more compelling, thus creating a virtuous circle. You need to buy their product because other people have their product.
The network effect of Jira is obviously at the department level; dept. head A mandates Jira. User B gets moved to new dept. C, we need some sort of project management tool - hey B what did you use when you were working for A, oh A likes using Jira, I didn't like it much but it's ok I guess.
Ok folks, let's use Jira!
Dept. Head A moves to Dept. D, hey everyone we are going to start using Jira.
Dept D. is being merged with Dept. E, Dept and new Dept. Head J is joining. E is using some open source Kanban solution based on CouchDB, hmm, let's go to Jira - other departments are also using it and then we can get rid of the CouchDB thing!
In point of fact where network effects of Jira is concerned, I have put some effort into learning JQL and setting up my own dashboards, so when you give me one of the competitors I get grouchy. I prefer Jira or Trello - also owned by Atlassian iirc?
another network effect of Jira is that it's usually set up using AD, so once it's installed and configured, anyone in that org can go and look around without having to create an account.
ISO (the standards body) has started using it, I'm sure in part because large companies who contribute to standards were already using it. The committee that I am a member of switched from Bugzilla to it.
JIRA's network effect is the amount of plugins and third party integrations that work with JIRA.
The author points at monday.com: I used it a few years ago and it only has basic and useless integrations out of the box, even for a service like Gitlab. You either develop what you need youreslf of try to so something with Zapier.
Everyone else is using it to write documents, email around drafts, collaboratively edit via OneDrive; sure you can use an alternative, but nobody will want to see a format but .docx, so your alternative is almost guaranteed to be worse than or equivalent to Word. If your alternative stuffs up the document's formatting you become seen as a pain in the neck. So it's just easier to use Word.
Every contract I've received or sent for red-lining uses Word and change tracking. I'm sure exceptions exist, but every lawyer I've dealt with uses Word as the defacto standard for contract negotiations.
> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).
My experience tells me the complete opposite of this statement. Regardless of the the workflows, automation and whatnot there are tons and tons of IP hidden in tickets and over a long enough period references to them end up scattered all over your tools, commits, documents, wikis, IM, email, etc. etc.
When you move ticketing providers it's very likely you can't correctly migrate all of your existing data into the new system without breaking or losing some of it.
I detest trying to figure out why a certain code change was made, looking at the commit message only to find a reference to link to a dead ticket.
I'm not for or against Jira, but moving ticketing systems does not come at a "minimal cost" in my opinion and needs careful consideration and motivation.
Coupling, it's a constant scourge all over in software.
Whilst I LOVE to crap on Jira, it has brought some magnitude of order and civility to the PMO's and at least created a familiar work environment for people.
God help me If I ever have to go back to word docs and sharepoint to manage project work.
I was (a very small, and only part-time) part of a team that did a migration from a Perforce-era VCS to git. It was about 6 weeks of 100% background work -- as in, we prepared cheat sheets, changed or rewrote relevant parts of the CI and deployment chain, while everyone in the company kept using the old VCS.
Then it took about 36 hours to move the relevant code bases (a few dozen repositories, some of them 20+ years old) over to git, including the entire commit history. This was pretty slow. It could have probably be done faster but we figured, since we only do it once, we don't need to invest too much time. We scheduled it on Saturday morning so it would be done by Sunday afternoon and we had some time to test it before Monday hit the earliest timezones.
We had a backup plan in place in case it didn't work but it wasn't necessary.
The two repos were automatically synced for a while, to allow people who had started work on something on, say, Friday morning, to commit their changes to the old repos, rather than have to replay their work on the new ones. After that the old repos remained read-only, but we preserved them because, obviously, our issue tracker had twenty years' worth of references to old VCS revision numbers.
So it took about 6 weeks of indulgently part-time work (our infra team worked several hours a day on this, I worked... about an hour or so a week?) to plot this daring plan, and about two days to make it happen. The total amount of work disruption was likely non-zero but certainly small enough that most people didn't complain of anything other than having to learn git.
I can't say about Bamboo to CircleCI but, having gone through one of these, I can say with 100% confidence that if you start out right -- that is, your existing repository is not a mess of stale branches and weird merges -- and you don't go about moving fast and breaking things, moving from even an ancient revision control system to git is not really apocalyptic.
Thank you for sharing your experience. Migrating from software A to B is part of life, Jira does not hold a special technical place. Politically, that's a different conversation...
I helped a prior employer move to github and asana through JIRA's own APIs. It's actually not that hard and the entire engineering group was very cheerful of the change.
Really? Was it easy enough to define mappings between all the various fields/ticket types etc? I guess you could do it per-team across an organisation.
It always seems hard enough to get information out of JIRA using JIRA when I watch our PO in planning meetings.
Yup, there was some mess around inexact mapping so we had our own conflict resolution and definition of what and how to interpret respective fields.
Honestly, JIRA easily has one of the most sluggish and horrid developer experience so the bar wasn't too high to begin with. Visual Studio Online / Azure DevOps is far better than JIRA ecosystem imo.
While Jira may have some unique features for developers, one of Asana’s selling points is how it allows non-homogenous teams (incl whole companies) to work together (and by themselves within individual teams) on a variety of different kinds of work (projects, processes, loose day to day tasks etc). And as for scale we have many customers with thousands of users (one tech customer of ours has 100,000+ users on Asana - most of them I’m sure would be product teams).
>> with minimal cost (other than the initial hassle of switching to a new system)
The first part does not realistically connect to the second part. Surely the author is aware that switching to new systems is actually quite expensive monetarily and operationally - definitely not “minimal”?
At my old company, they had two annoying jira workflows management wanted to tie in to the dev process
1) When the user wants to merge to master, at least one of the commit messages must reference a valid Jira ticket.
2) A Jira plugin was installed such that when tests were run in CI, a jira ticket was created to record the result (pass/fail). This somehow ticks a SOC compliance box
1) sounds pretty reasonable and standard to me, though a backdoor is usually necessary for PRs that are just to fix a build-blocking issue due a bad merge e.g.
Agree 2) is stupid, why would you need a ticket for a passing build? And unless you have a super stable CI system a decent % of failures are transitory and don't need tracking - but if your master branch fails to build on retry an auto created blocker ticket makes sense.
> That is, CTOs and CPOs loved Atlassian’s revolutionary Jira product so much, it was able to grow virally and organically without the business having to spend millions of dollars on an enterprise sales team.
Here people talk a lot about creating a good product, code quality, etc. It doesn't matter.
You don't need to build a great product: you need to find the market and exploit it faster than you can. The quality of your product is not important.
How is Atlassian with so many bad products is valued at $52 billion?
Jira is one of the worst products in the eyes of developers. But it does not matter.
Managers love Jira because with Jira it's "very easy" to create a workflow and micromanage everything. And managers decide what's good for the company, they have the power to buy Jira.
But Jira is not Vilain. The villain is the school of management through fear, micromanagement, etc.
I worked at a company that created an internal JIRA. It's worse than Jira. It was too complex to fill everything, we create a script to do this.
> That is, CTOs and CPOs loved Atlassian’s revolutionary Jira product so much, it was able to grow virally and organically
> Here people talk a lot about creating a good product, code quality, etc. It doesn't matter. You don't need to build a great product
You really haven't disproven that CTOs and CPOS loved the product initially, which I believe to be true.
So yes, you do need to build a great product at the beginning. Then at enough scale, your product can become shit in some ways, and you can focus on sales.
But the article's thesis is that Jira did not start as a shit product.
I have no idea what Jira was like in the beginning. But today Jira is a very bad product (in the opinion of developers), but managers still love Jira because Jira has found a market (managers, CTOS, CPOS, etc). Jira being a very slow and buggy application is not important.
As an example of a tool that found a market in the area of developers is Docker.
I used docker in some companies and my God, Docker is buggy as hell, sometimes I pull new code in git and Docker doesn't see it, I have a lot of network problems, etc.
And have no idea what Docker was like in the beginning, but when I used it, it was horrible experience, and developers continue to use it.
I'm very happy that my current employee does not use Docker.
> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost
That's just plain nonsense.
I dislike using Jira as much as anyone, mainly because it's so excruciatingly slow.
But there is no competing product (suite) that offers comparable functionality and provides the same long-term flexibilty. Many companies have built entire workflows (not just development related) around Jira, and have huge knowledge bases in Confluence.
Switching would come with a lot of effort.
I will say that most of the Atlassian products are ... not great.
Bitbucket has completely stagnated and is way worse than Github and Gitlab.
They actually had an opportunity there. Once upon a time Bitbucket was the only site to offer free private repos, and it attracted a decent number of users to also publish open source there. A good amount of companies adopted it.
But they let it linger and didn't keep up with Github or even Gitlab. Just like Jira it's also slow and awkward to use. (never do large PRs ...).
I see a lot of companies switching away from Bitbucket now because developers are not happy with it.
Bamboo ... meh
Opsgenie ... meh
Confluence is actually fine. If only it had better search and wasn't so slow...
And Jira is so complex, improving it is probably extremely cumbersome because so many features have to be considered and everything has to keep working.
It might be advisable for Atlassian to start fresh with a new ticketing system.
Anyway, they have 8000 employees... they can always drastically downsize and refocus, the company will be around for a while.
I like to call Confluence a knowledge cemetery - in the huge datasets you have in mind, finding the page you are looking for is more a matter of luck than anything else. And once you found it, you can never be sure if it's still up to date.
> Anyway, they have 8000 employees... they can always drastically downsize and refocus, the company will be around for a while.
I'm actually wondering how they can not make a profit with the huge corporate user base they have?
> I like to call Confluence a knowledge cemetery [...]
Spot on from my experience using it in big orgs.
The issue IMHO is that organization of knowledge is not following any system and/or no system that could be followed was ever set in place by the organization when they bought into Confluence.
It's kinda like ordering an Airbus because they're a reliable plane. Then you sell tickets and everyone is board of course because ... Airbus. But you never hire a pilot.
If organizations using
Confluence had at least one full time "Wiki Master" position or the like (with resp. superpowers), this wouldn't have to be like that.
I.e. I'm not sure the argument can be made that this is Atlasassian's fault.
>I.e. I'm not sure the argument can be made that this is Atlasassian's fault.
As someone who spends a lot of his work life administering Jira and Confluence, I disagree. The problem is that these products try to be everything to everyone and as a result users have a massive degree of freedom with what to do and how to order things.
With that amount of freedom you just have a bunch of end users, many of them non-technical, who have no idea how they are SUPPOSED to use it. Especially because they don't want to spend a lot of time learning the right way to use the tools. They have a bunch of other things to do and just need to interact with this tool to complete their current task and then move on.
You are right, a sort of Wiki-Master would help. But, at least in my organization, we don't even have enough capacity to do all the basic administrative tasks required like setting up projects, workflows, custom fields, screens, etc. We can't also manage the content inside. The users are on their own in that regard.
If you are not willing to hire stuff with the sole purpose of managing the content of your Jira and Confluence instances, a more opiniated, rigid product is probably a lot better for your organization.
> If organizations using Confluence had at least one full time "Wiki Master" position or the like (with resp. superpowers), this wouldn't have to be like that.
I think part of the challenge is finding and retaining this person. It takes a fairly unique kind of person to want/enjoy a (let's be honest) thankless job like managing and maintaining a huge corporate wiki.
Finding good tech writers or information science professionals has always been a difficult task in any company I've been at.
Documentation and wiki writing ends up being side-of-desk work for someone else, and so of course it never gets maintained.
I worked with an Atlassian consulting firm for a short period while at a big org. Needless to say the consulting firms recommend the big orgs to do things differently from what they do.
Jira - Everyone has the performance issue, to avoid it they tell them to carefully choose extensions and not randomly litter it, especially with extensions that conflict each other.
Confluence - They recommend to establish a proper structure in advance that everyone follows with templates that everyone can use(not the default ones), so that the cemetery issue doesn't happen.
That said, I haven't seen any company who's confluence wasn't a knowledge cemetery. But regardless of how much I dislike Jira, I'd still pick confluence over google docs.
Yeah Confluence is a black hole as far as I'm concerned. Search absolutely sucks, and it's made worse by how some teams store meeting minutes (and basically everything) there, so searching for simple stuff turns up pages and pages of useless junk.
Once upon a time, I was gainfully employed at a company that stored its tickets as flat files, using a homegrown ticketing system which was a bunch of perl scripts. Said system had the same name as the first name of the actor who played Jack Horner in Boogie Nights. It had all the good features of a text-based system ... simplicity and greppability being the biggest ones.
It eventually got replaced by some JIRA-like monstrosity, I don't remember which. All the text-based goodness was lost. The excuse for the move to a different system was "performance", which was half true. I'm guessing that nobody wanted to go fix it.
The point behind all this rambling is that yes - flat files can be made to work in the way you mention. It just isn't an approach that is cool enough.
If the entire company was just you and me, that'd be very tedious but otherwise fine. But even software companies have non-software people on their staff, who are less likely to know how Git works, but can spot some problems we developer folks can't see. We'd want them to tell us about it, but if we add too many hurdles they won't.
Agreed. Jira and Confluence search is easily the worst I've ever used and to your point it's more of a box to check for product people versus being useful to end users. It is absolutely where data goes to die.
> But there is no competing product (suite) that offers comparable functionality. Many companies have built entire workflows (not just development related) around Jira, and have huge knowledge bases in Confluence. Switching would come with a lot of effort.
Exactly. Other products comes with opinionated workflow or are much easier (and simpler) to use. Once you setup Jira way you wanted (good luck with that) and able to maintain this setup for all of your projects you're stuck with Jira forever - you won't be able to export all of your content to another software. The whole process takes ages and its a nightmare of going thought totally different UX pages, unintuitive settings, slow UI, setting up extremely expensive plugins (why till today you need to buy tempo to get basic functionality like time tracking) etc.
It's called vendor lock. Nobody ever got fired for buying Jira
Other products are not for every business, have limited settings - but are quicker, saves you time and are able to be useful since day one.
All of the companies are using Jira differently, even if you're familiar with this, and you have been using Jira in all you provious jobs for years you still need to have onboarding on how does Jira works in current company - as for instance I've worked with Asana in 3 totally different companies and workflow was the same.
One could say Jira is like SAP. Theoretically it's just a software, but in the end there is so much customization that the business starts to revolve around its processes.
True that, but it's not their fault, it's just their turf. They need to solve business needs for core processes in a sufficiently generic way to be applicable to any big enterprise. The only way to achieve this is through heavy configuration/parameterization.
>>But there is no competing product (suite) that offers comparable functionality.
But not everyone needs 'comparable' functionality - an awful lot of people use just some features and not others - because of the awful UI and terrible user experience, these people are ripe to be picked off by a competitor (existing or future). I agree, if a mega-corp is completely in bed with JIRA, its harder to switch, but for a company not making any money (Atlassian), having their small and medium sized customers peeled off bit-by-bit for better products is going to hurt.
The alterntive for companies with many departments is usually using a variety of tools that all need to be in sync. Jira can be the one point that handles all workflows for all projects.
Latest versions of YouTrack come with a knowledge base and pretty flexible workflows support. I'm curious why YouTrack never seems to be listed as a Jira+Confluence competitor, given the similar target markets.
even within one group I've seen some teams use gitlab issues rather than jira. It made a little extra work for someone I'm sure, but it worked fine. I think there are plenty of tools that do what a developer needs. Jira also does what the manager needs. If there were some good alternative for them, I think we'd see jiras hold slip.
Lockin is still an issue at smaller businesses. The boss doesn't care if it works well just as long as it work well enough. Trying to make arguments for better software based on ui/ux goes no where the higher ups just don't feel the pain of us plebs that have to use it.
>But there is no competing product (suite) that offers comparable functionality. Many companies have built entire workflows (not just development related) around Jira, and have huge knowledge bases in Confluence. Switching would come with a lot of effort.
Most companies don't need "comparable functionality" and most did not built entire workflows around it, and those companies will leave for competitors. The few that locked themselves into Jira will face sharply rising prices in next years, that will make them reconsider their choice.
They have bad products and they are losing 700 million a year, future for Atlassian is bleak.
I worked for a large department in a large bank that changed from Jira to MS Teams Scrum, as the new licence for Jira was too much. No way that it had as many features as Jira, but it worked fine, maybe was simpler.
We used TFS in 2010 to create issues and stories and development workflows and i remember it worked fine with no major complaints. Especially as a full VS shop ,it even had very good integration for everything which can be done inside the Visual Studio itself. We eventually moved to JIRA though couple of years later.
I believe that TFS product evolved to Azure DevOps now.
My client uses Azure DevOps for ticketing and scrum processes, and that integrates nicely with Teams (pipelines, bugs, user stories, etc). It works pretty well and can be customized.
My main problem with confluence is that it doesn't know what kind of text editor it wants to be. Sometimes its markdown (or rather its own undocumented flavour of markdown), sometimes its a rich-text editor, sometimes its just plain text, and you kind of figure out on the fly what to do. Also the codes boxes are absolutely massive and a bit of a pain to work with (which, like all of these problems, could be solved with just normal markdown).
In the grand scheme of things though, its a minor annoyance.
Jira is slow and Confluence too. I 120% agree. It's the biggest issue for me. The longer the page in Confluence the worse it gets. I use it for weekly meeting notes and every 2 quarters I need to start a new document because editing the current one causes the CPU to go brrrrr.
I agree. Jira is here to stay. It is like Excel - love it or hate it, but it has its use cases other products do not cover in total, only for certain cases.
I have never tried the JetBrains' alternatives (Youtrack, Space, etc) but considering everything from JetBrains is usually very good, I'd like to hear from someone who has.
Used Jira at the last company. Use YouTrack now. YouTrack is better, hands down. Much faster UI, more keyboardable, better integrated into the IDE, integrating it with CI and mailboxes is easy.
Caveats: new job is small so it's a small instance. JetBrain's own YT instance is pretty fast though, so I guess it can scale well. Also, we don't use the new KB/wiki feature so can't comment on that. It's probably got less features than Confluence. We don't use the scrum features.
Biggest caveat - I speak as a developer. One of the biggest problems with Jira was the culture that surrounds it. Clueless PMs who had never written software in their life kept creating fixed workflows in which you couldn't transition tickets to arbitrary states (for no apparent reason, there seemed to be no benefit to these rules). So we were constantly being slowed down by the need to get the handful of people with Jira access to edit the workflows and add more transitions, which was pure makework, especially as even figuring out who the admins were was remarkably complicated. PMs also had a weird Jira fetish, they were like, if it's not in Jira it doesn't exist. So they forced the project to change from a more normal SW dev project early on to mandating that every commit had a ticket associated, and that ticket had to be scheduled into a sprint etc. It was just rank stupidity. Want to do a quick refactoring, as part of your current task? Roll it all into one giant commit because otherwise you'll need to file a ticket. New place doesn't work like that. YouTrack is used more simply, like a todo list. Git logs are the source of truth.
I haven't used them for real but (briefly) evaluated with the intention to maybe replace Jira, about a year ago.
Space wasn't there yet. IIRC the main issue was lack of a way to set custom fields via API, or some weird restriction around that. My general impression was that it was promising but too immature at that time.
For any Jira competitors reading this - start with providing 2-way sync between your product and Jira instance. It would make moving away from Jira soooo much easier!
The current state is that even importing Jira data is below what I'd expect - e.g. Linear (last time I checked) didn't import comments at all and all issue IDs were changed to new ones. Really, if there's FOO-123 in Jira it's table stakes for it to be also called FOO-123 in the new tool.
I wrote a tool to migrate an issue tracker to Jira which imported everything as expected and updated links in issue descriptions/comments to keep their integrity. It took few days for a one-time migration so I'd expect someone who builds a business in this area to just have that as a baseline. It's sad how bad the "import from Jira" journeys are.
Jira has a search bar which seems ok-ish. Except that I have to wait 10s after I open Jira for the search bar to start working because it's probably the last thing to become interactive after a page load :|
Confluence is the single, worst Atlassian product, in my opinion. I describe it as a wiki written by someone who has never used a wiki. It seems like everything about it is wrong in some way, and it's painful to use.
I've been recently forced to use Confluence and I'm blown-away at how horrible the editor is. It feels like it's a beta-level product. For what it costs I'd expect it to be on-par with, say, Mediawiki and it's just not.
It used to be fine. The absolute worst of the recent changes is that they got rid of the ability to make a link to a new page by creating [the link] in square brackets, and then clicking on the link once published. Now you can only create links through their menu (or a keyboard shortcut), and only to pages that exist already. IMO when that feature was removed it stopped being a wiki.
I think you misunderstand the way some companies work... Some companies, a VP will send an email saying "As of next week, we will use Asana instead of Jira. Jira will be deleted, so copy anything important off it now. NO EXCEPTIONS!"
Sure, there will be mayhem for a couple of weeks, but the migration will be successful. The VP will have one more thing to put on his 'done' checklist.
While Trello is simpler and snappier (not snappy, but snappier) than anything Atlassian has to offer, it is quite limiting as well for task organization.
One problem is, that not everyone is willing to educate themselves and people expect to be able to use things immediately. This causes the push to dumb down things into a limiting experience. If I were surrounded by only technical people, then a plaintext file like an org-mode file with predefined todo-labels, commited to a git repo would beat all of the Jiras, Trellos or whatever out there and it would cost not a cent and be safer to work with, as everything is stored in git.
Every time there is an update I wonder what feature they removed or is broken. I still cannot properly add images in lists or continue the numbering in a new list to work around this "feature".
They also broke markup/down import which is another kind of hell.
Last update we had resulted in markdown only being imported if you paste it into the document using shift-insert, ctrl-v didn't work for some reason, can only assume they want to kill it off.
> I dislike using Jira as much as anyone, mainly because it's so excruciatingly slow.
But there is no competing product (suite) that offers comparable functionality and provides the same long-term flexibilty.
This is maybe true, but the future belongs to more flexible software. Eventually Notion [1] or Fibery [2] will replace Jira. They may do it now for smaller team already (10-500 ppl), it just takes time to enter large companies.
I agree that Jira is too complex, which makes it slow. It's also way too customisable at the project level, so moving to scaled agile is hard because of it. Honestly, it's easier to start again if you want to be successful with SAFe.
If Atlassian wants to be profitable, they need to replace their founding CEO's. Mike and Scott have done well to grow the business, but the required skillset is different from this point on. Mike in particular seems to be very distracted these days.
I agree licensing / costs have become less attractive especially at the lower end, VC funding ruins so many software companies - I hope they can overcome it.
It has been years, since I wrote in their little feedback box, that it sucks and does not properly support Markdown. They do not give a damn and they are not going to fix their issues. Best to look elsewhere for an acceptable wiki experience.
You don't need most of those comparable functionality AND you can get decent UX
Simply put, Atlassian sucks at building products because their culture is not good. They got lucky they had the right idea when they were young and didn't have competition.
Nowadays there are just better products out there.
I am not convinced that would amount to anything useful. Their engineering culture does not seem to be up to the challenge, judging from the quality their products have for many years now. They would probably only produce an equally bloated piece of software, that does not work properly on all major browsers and gaslights you about your choice of browser, because they were not able to stick to standards.
They need to go the way of Telegram and build parallel products themselves and let the better one prevail after some time. Basically build your own competitor in-house.
I am:
a) a dev myself
b) head of a small dev/SAAS company/team
c) Atlassian Marketplace vendor
Jira is fine. Atlassian will be around for quite a bit, imho. They have a somewhat decent ecosystem, which helps a lot with the stickiness.
Jira could see a lot of improvement product wise, but at least it has been getting faster in the last year (still slow, though, but not as bad). Their new stuff seems to be a hit or miss, but I especially like their new Jira thing (Jira Product Management), mostly because it comes very opinionated.
I think Jira/Atlassian would benefit a lot from actually providing more guidance on how to properly use their product(s) depending on team size (e.g. moving from 5 to 50 to 500 person teams). Most other tools don't do this as well, but I think that would improve the experience for everyone, dev & mgmt alike..
This article's finger is on the right place, but IMO the analysis is off.
Netflix, has recently excited the fundamental/rationalist investor camp. The huge valuations hot tech companies enjoy must eventually be justified by a "Thiel Monopoly." That's the only way to earn the 20%-50% margins that Google/Apple/Meta can achieve. Netflix sells a cheap consumer product. One product among several similar options. Consumers are savvy, with many jumping between subscriptions for deals and variety. Content producers have market power, because multiple buyers.
In short, textbook microeconomics is afoot. That means competition, efficiency and low margins. That means "startup economics" don't apply. The market is not going to let Netflix sit on massive margins and monopoly market share. Newschool tech investors see this as an abomination. Old schoolers see it as cosmic justice.
Anyway.. those who desire market rationality love Netflix and are applying the Netflix analysis to everything.
Atlassian is a different story entirely. They actually sell software. Enterprise software, really. There are no content producers squeezing them for a bigger cut. The companies who pay them aren't price sensitive, and they are locked in enough. This is not the "microeconomic normality" monster that bit Netflix. Atlassian's business model is fine. Competition isn't the problem, and neither is consumer bargaining power.
Atlassian's problem is that they haven't done good enough. The bar, set by both tech history and the $150bn peak valuation, is that Atlassian becomes a microsoft.. at least a SalesForce, IMB or somesuch. Where's Atlassian's challenge to AWS? When is Atlassian leading the WFH revolution. How will Atlassian become the organisational nervous system of the modern knowledge firm?
It just doesn't look likely that Atlassian is going to achieve that kind of big-hairy-goal. The products have a crusty, uninspiring feel. The take over the world vibe is missing.
So... Atlassian's valuation is down. I doubt the share price will ever approach "rational." Software companies have value, and the floor is set by opportunistic M&A. If stock markets don't want TEAM @ 10X revenue or more... someone will buy them.
> The companies who pay them aren't price sensitive, and they are locked in enough.
I doubt this is true lately. I have seen even more critical ticketing system like ServiceNow/Cherwell/Remedy getting replaced. We replaced Slack with other chat software because of licensing cost. Big companies are not price sensitive seems like old theory. Because I am seeing in so many large companies increasing license fee is causing replacement of existing products.
> revenue for the past nine months grew from US$1.5 billion to US$2.04 billion ($2.95 billion) (or around 24%).
Forgive my math skills at 4:07 in the morning, but isn't that actually 36% growth?
> Atlassian’s legacy Jira product ... is no longer loved by developers.
As a developer I prefer Jira over every alternative I've tried (Clubhouse, Trello, GitHub Issues, and Monday.com).
> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).
That seems like a pretty big hassle though. My company is way too busy to undertake switching ticketing systems.
> As a developer I prefer Jira over every alternative I've tried (Clubhouse, Trello, GitHub Issues, and Monday.com).
I also prefer JIRA, but that doesn't mean I love it. It just so happens to be the only available product with most of the features I need.
That being said, its UX is beyond terrible. The moment something else appears that covers some significant portion of its feature set, I can see a lot of people making the switch.
I think one of the biggest problems of competitors is to think that JIRA is bad because it's complex. Therefore they position their offerings as a simpler slim down version of JIRA.
Big news: it is complex to manage complex projects. JIRA has, I think, the right level of complexity and flexibility to tackle that.
If any competitor reads this message: please, go complex!
It is very fair to ask oneself - where will Atlassian be in 10-15-20 years? JIRA is slow as molasses, and ripe for disruption. It Atlassian themselves won't do it, others will try.
In the end - if you're an investor that's exposed to Atlassian, these things do matter. And the article is being fair on that point - do you think Atlassian is worth what it's worth, and if so - why? If the answer is "customer lock-in" and "no real competitors yet" well, plenty of companies in the yesteryears were also in that spot.
Oracle revenue is up 5% at $11.8 billion and they have a strong and growing presence in the Government Cloud market. So really not doing too badly at all.
> that is, users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).
I can tell the reporter has never used or operated something as integral as a ticketing system at scale. These systems are integrated everywhere to automate operations flows. They’re used to continuously enforce compliance. The list goes on. Ripping them out at an enterprise company is very painful. Then on top of all that, you have to re-train everyone on how to use a new system.
> Combined with employing more than 8000 people, this means that Atlassian is unprofitable
In 1991, Microsoft had 8000 employees. It was producing DOS, Windows 3*, Office, OS/2, tools and compilers. Windows NT was in development.
They did not use Jira.
I think the main feature of these tools is to make people, who would otherwise be unproductive, feel and look productive. Maybe those people are managers that should never have managed software development. Idk.
They also built pyramids without excavators but that doesn't mean it's not helpful. Just because old systems could be built without specifically using jira, by itself, is not an argument. You could make the same argument that, clearly, we don't need Java or JavaScript because we also got by fine on Fortran and C in the past. Without doing an actual comparison, it's just as silly an argument as the claim that these tools' main function is to make you feel more productive than you are.
> They also built pyramids without excavators but that doesn't mean it's not helpful
False analogy. The point here is that productivity in old Microsoft was far higher, and that the failing piece in modern development might not be the ticket system.
> The point here is that productivity in old Microsoft was far higher
That sounds virtually impossible to prove between unequal situations, and especially "far" makes it seem like an exaggeration / tall order (productivity between people isn't like wealth or popularity: some things change by multiple orders of magnitude, but how hard you can work doesn't, especially when averaged across thousands of employees), but to be fair I didn't read the whole fourteen thousand word source you added so I suppose I can't say for sure.
The actual lines of code in an OS has balooned exponentially. Of course we can’t discount the abilities of the average software engineer in the 90s vs now. I’d guess back then you had to be fairly driven and smart to be employed there, which is not necessarily true anymore. If you have a pulse and can barely pass fizz buzz you’re employed with 200k salary, so yeah.
I most definitely know more people than I would prefer who can only barely pass fizz buzz and make more than that. It is kinda interesting how dev compensation is in fact bimodal and the engineers (and the managers) in the second hump want to actively avoid any mention of the possibility that they’re under compensated.
> If you have a pulse and can barely pass fizz buzz you’re employed with 200k salary
If this was true; it is not an "efficient market" we are observing, neither in SaaS or developer employment. These companies would be outcompeted. The underlying mechanism that enables this is probably SaaS/etc lock-in.
Will be interesting to see what/how overturns whatever paradigm this is.
Every once and then they buy a startup to inject themselves with new blood and maintain their dominance. They also need to have decent leadershipt to make the right decisions (eg. I'm sure Ballmer would have killed M$).
They can afford all those useless employees because software allow you to get lots of profit with little work.
That also ate a lot of small healthy business pie in the market. I have mixed feeling about this. Do you think a company's R&D worth sucking a chuck of opportunity for small companies? I don't believe the niche vs. mass is less overlap. Imagine the market where there were no excel/spreadsheet/word. The customers of the market is spoiled by cheap/free/network-effect-koolaid plans just for sake of growth.
Let me go ahead and flex my MBA knowledge for all the engineers in the building who claim that MBAs don't know anything about business...
First, I suggest you read Atlassian's balance sheet and income statement. They're a public company, so it's all publicly available information. [1]
Look how fast those revenues are growing.
Look at how Cost of revenues is declining against the revenue. In 2019, it was 33%, 2020 it was 28%, 2021 it was 25%. That means that as Atlassian's subscriber count increases, its cost per subscriber is decreasing, a direct contradiction to the claims made in this article.
In the statements of cash flows, you'll see that Net cash provided by operating activities increases every year. Financing activities explain losses, not any sort of problem with the fundamentals of the business.
And, when you're losing money, you don't pay taxes. Atlassian is doing a standard business/accounting play here: re-invest in the business and use financial activities in order to pay nothing to the Australian equivalent of Uncle Sam. Income tax expense is a negative number on the balance sheet each year.
The worst claim in the article is that Atlassian represents a "legacy" product. No, not at all, especially if you've been on their cloud products anytime recently. The cloud products get rapid iterations and improvements, including performance.
Atlassian's pricing is extremely competitive, acting as a "bundle" that competitors can't match. Jira in particular has basically no realistic competitor, and OpsGenie does the same thing as PagerDuty at a fraction of the cost.
I am by no means an expert in the valuation of companies, but I understand primary school level math.
If Atalssian has a revenue (not profit, revenue) of $2.95 billion, how on earth can the stock market capitalization be $162 billion? If that was the profit, there would be a yearly interest rate of 2% on the stock value, which is pretty good in today's financial market conditions, but it is the revenue of a 20 years old company that never had a positive PE. What is the expectation of the market? A new killer product? Total dominantion of the issue tracker market (which btw also includes Github"? I do not get it.
I don't think it's crazy. You're valuing the company as a mature dividend paying company - one that is paying out to share holders the profits it makes, not investing further to grow. But that's not a reasonable way to value Atlassian, they're a growth company.
I think the expectation of the market is pretty simple, Atlassian grow by 30%+ YoY for the foreseeable future, which isn't totally unreasonable, and that their costs aren't going to scale with that growth because they're a software business.
If they grow 30% YoY for the next 5 years they'll be pulling in $10Bn in revenue, and maybe sales scale proportionally so call that 25% of revenue, R&D stays more or less flat at $1Bn - let's double it to $2Bn to be generous, Administrative stays fairly nominal at 500m. Hey presto, you've got a company with a tidy $5Bn annual profit. Discount that back to todays prices and that doesn't sound crazy. And all that is assuming is that Atlassian is fully matured in 5 years and not still growing.
To be clear, this is all just very hand wavey numbers, but it's not totally incredible.
I didn't realize that they were unprofitable; not good.
I don't think they should be valued as a pre-profit/pre-revenue growth stock - as the article says - the product doesn't really have network effects or strong lock-in.
> JIRA has huge feature creep lockin along the likes of sales force.
Sure Jira has lockin, but so does any tool with any features. Git has lockin, but you don't hear of people avoiding branches in case they need to move to perforce.
> Any new company probably wouldn’t use it though, it’s just overkill.
So what should they use instead? The thing about jira is it does the basics well, far better than any of the competitors we evaluated. Sure it's not perfect, but no tool is.
> Git has lockin, but you don't hear of people avoiding branches in case they need to move to perforce.
Replace Git with SVN in the comment above.
Also replace Perforce with Git in the comment above.
Then you have a viable argument and a story of mine that actually is a case of exactly that - back when project management for certain projects was done primarily in SVN, there was the expectation to stick to the popular way of laying out repositories, with folders for trunk, branches and tags, a bit like the example here: https://stackoverflow.com/questions/2611237/subversion-repos...
Of course, you didn't really need to do it that way and certain other projects explored other options, such as having features under the root of the repository, like "/ISSUE123" or something like that.
Well, as time passed, it became apparent that SVN just wouldn't cut it (TortoiseSVN was such nice software, though) and that the projects would need to be migrated off of SVN and into Git, to import them into GitLab/GitHub or elsewhere. Those projects all still being in development and having the need to be trace back changes to particular feature requests/issues meant that all of the revision history would also need to be moved over.
The problem with most of the migration scripts, however, was that they broke when you had a non-standard layout and as a consequence of that, you simply couldn't finish the import process and were stuck on SVN. Back then I actually resolved it by rewriting the history of those repositories into the standard format, but it was just a massive waste of time and a headache.
Alas, a sentence like this would absolutely be false:
> SVN has lockin, but you don't hear of people avoiding non-standard repo layouts in case they need to move to Git.
So yes, despite there being certain features and the ability to do something, that doesn't immediately mean that you should jump right in and use them! I might also have a few horror stories about Git submodules, or maybe even using Git LFS with synchronized Git repositories across GitHub and GitLab (of course, the LFS contents weren't sent properly, so no binary assets were mirrored), as well as other such problems.
If you can, stick to a stable, boring and predictable set of core features in any software package.
In my career I have repeatedly seen people regret ignoring portability. Some times because the old supplier went out of business. Some times because CEOs had a big fight. But mostly out of carelessness. I do not really care as it has been a source of a lot of my work. But it is very important: Be portable.
What happens if you get kicked off AWS?
What happens if Oracle goes broke?
What happens if Sun decides it will not let Java run on MacOS?
Etcetera. Often there is limited possibility for portability (people often thought programming in Java made things portable - they were partly right) but each element of lock in you allow must have a very good reason.
In my experience it is usually not a consideration.
This is what I'm reading the comment thread for. Unprofitable on paper, or unprofitable as in a shareholder is footing the bill personally for no apparent reason all these years?
Because at this size and age company, that seems unlikely, you'd have to be very rich already to be able to fund such a thing for so long, and have very strong belief ("any day now!") to not cut your losses all this time.
imho Atlassian's problem is that they failed to capture a critical mass of SaaS services for software development. Everyone uses GitHub, which provides a (crappy) bug management system. Everyone uses Google Docs which is arguably better than Confluence for most purposes. Perhaps not coincidentally both these services are owned by companies that make their money from other things so they can afford to dump endless investment in making them better.
> so they can afford to dump endless investment in making them better.
Which is so necessary when your product is very reliant on integrations because maintaining that kind of software gets so cumbersome over time. The testing alone can sink a team's productivity.
I work for a Confluence competitor and we've based our go-to-market strategy around executing one problem very well as opposed to trying to build a set of products to sell as a suite and it's worked relatively well so far. Business people love the idea of integrations and some of them do act as a force-multiplier in productivity. But they also create tons of headaches for end users and can be very expensive.
No wonder, given the "quality" of the software they deliver.
They claimed to support Markdown in Confluence – It does not work as good as any decent Markdown parser you can install in any mainstream programming language and does not understand, that within Markdown there can be HTML, for example for heading link targets and TOC. Same for Bitbucket. What are they doing? Letting interns code incomplete Markdown parsers and deploying them for everyone to haunt them with subpar quality parsing? The thing cannot even render a readme.md file correctly in Bitbucket.
Everything is slow to no end, downloading 20+ megabytes (no joke, no exaggeration!) for displaying a friggin git repo and the files list.
Wiki pages that the search function lists suddenly become unreachable.
WYSIWYG editor on Confluence is still a joke and annoying to no end.
Any technical person, who has ever used any decent alternative will run for the hills, before using that unholy combination of software, that is Atlassian. Jira is probably still the best among the bunch of utterly bad experiences and its UI is just terrible. Cannot find anything easily there.
We have tried many things and jira is just the most future proof. The others all fall short of with this ‘do one thing and do it well’; that is great but life is dynamic so that one thing doesn’t fit growing companies or small companies (depending on what you use). Like someone said before, you can run small teams with basecamp, but when you go into the 1000s of devs and other skills that all need to be managed on different levels over different skills and departments, it won’t work while in jira it does. Some people will say; use basecamp for the small teams and other solutions for managing; sure but then people have to switch environments or you are making custom stuff on top. Why if jira already does that? And you can also build those custom things on the jira rest api by the way.
It is not great but the rest is just not any better (as far as I have seen that is!).
One of the things I've found really interesting is how little development ecosystem there is around Atlassian's tools. They have a pretty rich API for most of their products, but nobody really uses them. There's some very cool CLI tools just starting to evolve for Jira and Confluence, which can completely transform the complaints people have (automating common concerns, eliminating UI slowness). I think Atlassian should have done more to build a community for people to ramp up on their technology.
To me, the problem with many of Atlassian's products is that they aren't tools. They are platforms on which you can build the tool you need. They are way too configurable and flexible and as a result, you spend a lot of time managing the tool or organizing the information and configuration within it. Tools should serve a specific usage, behave predictably, help you use them correctly, then get out of the way.
Jira Data Center is an unbelievably powerful tool.
It suffers from unknowledgable administrators.
If you have a person who is running Jira Data Center that is familiar with its internal classes, API, Scriptrunner, Automation for Jira, and the enormous 3rd party plug-in environment, there is simply no comparison. It’s not even close.
To be fair, that’s a pretty big ask, in terms of technical know-how and cost. Even just base Jira is quite complicated to configure well.
> that is, users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).
Hilarious.
Ticketing systems are very sticky, they are basically the original "no code" system, with years of business processes hacked into them, and users who are accustomed to every pixel of the UI.
> Atlassian’s prospectus noted that in 2015 the business grew by 48%, around double this year’s growth.
If Atlassian is 20 years old now, that means it was over 10 years old (~13) then. Atlassian was an enterprise service company at that point already. What kind of enterprise service company can be expected to maintain a 50% year-over-year growth for nearly a decade? If that's "around double this year's growth" that means they're still growing by 20-25%. That's impressive.
I'm not saying the valuation correction is wrong or that the claims they're unprofitable are unfair, I'm wondering what made anyone think they'd perform better than they have in terms of growth if that growth is already impressive. They sell enterprise services ffs and they're the gold standard outside e.g. Sharepoint.
Maybe the problem isn't their growth rate itself, but attempting to build the business model on an unrealistic growth rate.
Now the remote thing could be fantastic. I don’t know what the building on Harrison St. cost, but between what they save on staff relocations and real estate, there should be some offset in two-three years, right?
Salesforce is an Apple to Atlassian’s orange. I would guess they make more money from Tableau than Atlassian do from Confluence and Jira Data Center combined.
“Tableau Software generated $464 million as part of Salesforce for the quarter, up about 18% from the same quarter a year ago“
What will be the total cost of maintaining a Java app (with deep dependencies) for five years? Will subscription costs increase YoY to match?
Add to that the coupling of disparate products and their code and cultures.
I don’t see why this is a problem for society. Things rise and they fall. That’s markets. The guys who have created it are billionaires, they helped a lot of people. Now it’s time to move on to more modern things.
Similarly with decentralized projects like Bitcoin. I have come to appreciate Moxie’s stance on decentralized systems moving more slowly. It’s a trade-off. Can any Bitcoin maxis please tell us why we can’t look to newer projects for solving whatever it is Bitcoin was supposed to do but failed to achieve - be a peer to peer cash system for example? How about other applications like voting… why always and only Bitcoin, a 13-year-old project that barely evolves?
I like both JIRA and Confluence. I think many bad feelings towards JIRA are actually related to bad configuration. Like customizing the issues to add too many mandatory fields or creating a process that does not really match how people are working in practise.
JIRA configuration is pain. Unless you are large enough to afford a dedicated JIRA admin, it would likely make sense to just pay for somebody once in a while to implement the stuff you want.
All my bad feelings are almost completely related to the horrible search, terrible UI and the hilariously bad performance of the app. The web app has two completely different markdown adjacent formats that are not compatible with each other so you get text rendered one way when you create a ticket and another when you edit it later. Search is almost never helpful beyond finding recent tickets. Multiple pages take so long to load abs the new UI is so laggy and busted
- default text size is too small, text block widths are often not constrained enough getting the "slashdot unreadability effect"
- 0.5s+ lag when clicking any textbox
- 1s+ lag when clicking any dropdown
- 1s+ lag delay when grabbing and trying to drag-and-drop to reorder items in the backlog
- 2s delay when clicking in an issue in the backlog before the loading starts (add about 2s more for the loading itself)
- "Link issue" using a hyperlink icon. The whole idea of using the word "link" to talk about related issues without spending some time to think whether that's really confusing with hyperlinking
- Error messages about what "might" be wrong with things rather than what is actually wrong: "We couldn't save your comment, it might be empty or have invalid formatting". Well which one is it? Did you really have trouble deciding whether my comment is empty or not? Be specific and tell me what exactly is wrong, or do you want me to binary-search / bisect myself?
I think most of the issues can be fixed by completely rewriting the frontend.
Jira? Yes! Properly self hosted with skilled SysAdmins which don't allow every employee to install their favorite plugin. Then it runs fast and reliably.
The UI is very configurable and has many power user tools, like their search is very good and has so many features.
The Language for writing text is bad and sadly not even the same on other Atlassian products. Please just let me write markdown.
Confluence is another story. It is one of the better tools for documentation, but it's generally slow no matter who runs it. It has very quirky drawbacks like a page needing to have a unique name in a space even if it is in a completely different tree structure.
The editor itself from confluence hangs so much and has destroyed pages multiple times for me, thankfully the history is decent and you can recover usually.
I don't know anybody that likes using JIRA, but to be fair I don't know anybody that likes to use Asana either.
I might be wrong, but I think those tools are dedicated to something people don't like to do by default (planning, going through bureaucratic processes), so they don't like the tool either.
But for some reason, they convince themselves that they don't like to go through Bureaucratic Processes because of JIRA/Asana/etc... and that if only the tool was better it would be a breeze, when in my experience the process is the real issue, rarely the tooling (even though it surely can be improved)
Asana shows a flying unicorn when you complete a task. Makes my day every time.
A bit more seriously - it's not only about Bureaucratic Processes. UX matters. If you need to deal with "Bureaucratic Processes" using a terrible UI, it makes things worse.
Jira's UI is notoriously bad. Very slow. And the worst of all are the UX inconsistencies in Atlassian's products. Things behaving differently in Jira vs Confluence or even within Jira itself. For example, being able to use markdown when creating an issue but not when editing it (or vice versa, I don't remember).
I hate it. Being forced to document crap in a pile of tens of thousands of documented things is insanity. Nobody reads that stuff, but because it's documented, you can always say: "Wait, did you not read the documentation?"
Work goes faster if you keep it in small teams and let them self-organise.
I love this approach the team can pick which tooling they want to use, github wiki, readthedocs, docx on FTP, whatever works best for them. Each teams has its requirements. I don't see PMs using git/markdown to write their documentation, the same way don't make me write an API documentation on Confluence.
I liked it when I first switched to it from whatever was I was using ~2010 (Intervals, I think…). It still is somewhat better than a lot of task management/workflow software that you commonly find in enterprise. But it’s kinda just become another version of the thing it was supposed to destroy. The huge, complicated, bureaucracy management system.
I use Jira at work with a workflow that is highly customized to our development workflow, and I like using it.
There are some annoying aspects, but it's way better for our workflow than anything else I've tried (which includes github issues, gitlab issues, OTRS, RT, trac and a few others I've forgotten by now).
Over the past few years I've gone from despising Confluence to really, genuinely enjoying authoring in it. I find the syntax and shortcuts easy to remember and the UI pleasant. Hell, I even like the iOS app.
Jira and Bitbucket, OTOH, the less said about them the better.
Confluence has always confused me. Every aspect of the product sucked when I used it several years ago.
There was little to no discoverability, it was slow as shit and the editing tools weren't that good. The integrations to their other products were at the time pretty much non-existing as well. Always felt like it was really basic which made me wonder how it could be so slow.
Any other wiki software were probably better. Mediawiki is free but people still paid for Confluence.
I don't get why people used it and still use it to this day. I dislike pretty much every of their products though, they all suck in my opinion and I have written several JIRA plugins so I had extensive experience with it.
I like Confluence. It does the job and is simple to use. I use it at home for general household stuff and projects.
At work we are using a combination of notion and gitlab wiki and are probably going to move to confluence. Gitlab wiki is especially hard to use and thus stuff is under-documented. eg I'm a little project right now, we could use about 20 pages to document bits of it, this is such a pain in gitlab wiki.
I use Jira, it is okay. I think a lot of people here hate it because they associate it with Enterprise paperwork and rules.
I tolerate Jira (even though it is too slow and clunky to me). But I despise everything else from Atlassian. I don't understand how people can stand using Confluence or Bitbucket.
Anyone using these products has no choice, so, I would say that these products having any API at all that can cobble together automation is a huge blessing.
We have wrapper functions that allow us to automate all the painful interactions with atlassian software. None of them are clever in any way; they're rote. But without them, we weren't using the services fully, which is sophomoric since we don't have freedom to use other services.
I really liked, when I used them, how well integrated all the tools were: BitBucket, JIRA, Confluence...
You could see PRs related to a given ticket, see tickets in wiki, I'm sure it integrates well with CI (Bamboo/Pipelines?), etc. It might seem small, but such integration makes work more pleasant and comfortable.
Like many, I would rejoice to see Jira die in a fire.
But the fact is that if that happened, another tool would be used instead, and the same dysfunctional management processes would just re-emerge. Jira makes micromanagy bureaucratic process easy, but does not in itself cause it.
I love JIRA. It's versatile, as simple or complex as we need, integrates with many things and drives processes in the org.
People have many objections to using JIRA but often these are not about the tool but about the management procedures the tool serves.
I don't mind Jira. We're using Github Projects (because for OSS project where people report issues to the repo) and while new Projects has gotten significantly better, I do still miss some of the planning views that Jira gives you.
I have learned a lot of the hate towards jira including my own is the difference between a well setup config vs a bad one or where many people are, using it out of the bud.
It seems clear to me that they are a company that no longer cares about strategic investment.
Their forays (acquisitions) into version control have been so amazingly weak. Stash was devoid of even basic features. Now they have Bitbucket:
- they still can't get it to perform adequately after years
- it lacks syntax highlighting in PR views
- it took them years to get side-by-side diffs into PR views
- it integrates with third party tools poorly
I thought maybe the Github acquisition would spur them into recognizing it as a important product category, but I guess not.
Thats the only measure of real profitability - GAAP.
Free cash flow includes stock based compensation. Thats a real expanse and turns negative cashflow to positive. But it dilutes existing shareholders, you would like to see positive cashflow EXCLUDING stock based compensation
If GAAP is the only measure, then Amazon and Salesforce have been utter failures for 20+ years, only returning 120,000% and 4000% returns to shareholders.
In fact, if an investor went by GAAP, he would have missed the entire massive SaaS boom of the past decade.
The high growth without generating a profit has worked fine for them for the last decade. But it seems that their stock price is in risky territory. They were valued at 113B at their peak and are now close to 48B. But their annual revenue is just around 2B. So that is still 24x revenue with no profits. It looks like they would fall a lot more if that revenue growth slows down due to a recession or companies just cutting back a litte bit.
Am i the only one who finds trello more than enough? Agile is meant to be lean, but instead its become a blob full of nonsense in part thanks to tools such as atlassian’s jira. With basic tools like trello you define a slim scrumban workflow and focus on actual work. There are indeed use cases for stuff like jira but it feels like 99% of the time jira is not necessary.
> Atlassian’s legacy Jira product is clunky and has barely evolved in a decade — it’s essentially a ticket-based system which allows developers and product managers to communicate on tasks and is no longer loved by developers
Developers "loving" any ticketing system is a bit of a stretch. To me it's more of a "least worst" preference.
I notice that the share price started to plummet just after the announcement that they would be dropping support for On-Prem customers. That's basically saying goodbye to most Australian Federal Government departments. I know we used tons of on-prem Atlassian stuff at my client and we ended up transitioning everything to ServiceNow.
It's tough for me to square with the JIRA hate. I don't mean to simply be contrarian here, I have limited (<6 months) experience. But the alternative horrors I've been forced to use - like Rally or a couple internal tools that were highly neglected - I can't imagine it's really _that_ bad...
Atlassian did well in replacing the barren world that consisted of Bugzilla/Trac/etc (yuck) and worse closed-sourced offenders like the "Rational suite" (the worse pile of crap I've ever had the displeasure of dealing with)
But yeah, somebody should create a Jira ticket for their lack of profitability
Massive pile of garbage is more like it. As a developer, the only thing slowing me down from getting work done was waiting on JIRA and being told to use the crap they call Confluence to document things.
Honestly, Azure DevOps is a solid replacement. The integration is really good and the "Boards" software really feels like they're eating their own dog food. Their Wiki software is Markdown stored in a Git repo (unlike Confluence's mess). It's fast, permissions are relatively intuitive and fast, etc.
It's worth a look if you're evaluating.
JetBrains Space is another alternative, but I have no experience with it.
Treat it like a software problem, start with the simplest thing that'll work and then introduce more complexity or features when you need them. Chances are you'll start with GH issues or a shared doc in a productivity suite and where ever you land, it won't be JIRA.
Confluence search has a lot of issues. Its almost impossible to search for documentation or anything there. Even Slack search is leagues better and can be used as a documentation/ help tool.
It's not great but it's not that bad. A business has to have documentation and has to have a standardized workflows around doc. Jira/Confluence is not what I would choose but it works OK.
Just a random, semi-related thought, but maybe if there is a recession, then software as an industry will become more connected to business/engineering fundamentals? I see a few people mentioned Jira busy-work here... maybe the market will actually correct for all of that?
Reading through the comments two things stand out:
- People disagree on whether it is appropriate to focus on growth or profitability at this stage in Atlassian's lifecycle.
- I suspect people project their misgivings with the products onto the company.
Other than the points raised here by others and in TFA’s comments section which point out TFA’s flaws, I would add only that there are worse things than Jira --- as I found out When my final employer converted from Jira to ServiceNow. If you think Jira is bad... jeez.
>CTOs and CPOs loved Atlassian’s revolutionary Jira
CTOs and CPOs affection to useless crap designed to impress clueless managers and hated by everyone who actually has to use it is kind of a common pattern.
When I worked there, they disclosed all financials in our internal Confluence site. There was a policy of full transparency with the employees. The owners (Mike and Scott) had impressive business discipline. They were profitable every quarter. They had many many opportunities to get vc money and go wild. When they finally took VC money, It was a modest amount ($60M I think) and the purpose was explained to us as setting up an ESOP program and putting Atlassian on the path to go public.
A year or two later, Doug Berman, the founder of Great Plains software became chairman of the Atlassian board. He gave a presentation to all of the employees at the Sydney office. One thing that stood out was that he said, it's actually bad to be profitable when you're growing. I'm paraphrasing here but he essentially said, you're leaving growth on the table. His thesis was growth is more important than profits.
So whether you agree with that or not, that is obviously the idea they are operating on rather than uncontrolled spending and helicopter dropping stock on employees heads out of desperation.