Waiting is also a risk averse take and many organisations don't want to wait and are prepared to spend extra
Not only is predictability very important for publicly listed companies if they want any investors what so ever, many organizations older than say 25 years have a near constant hangover caused by poor tech decisions they've made in the past, redundant duplicate systems due to mergers and acquisitions, half-finished attempts to migrate a COBOL system to something newer, an Oracle DB license that costs a third of the IT budget they can't migrate off. The older the org the nastier it gets.
This is why the business world not only runs on Java, but old Java, it's why AAA game studios keep rehashing the same safe bets rather than trying something different, why Hollywood has turned into an assembly line for making superhero movies, why the sky is full of airliners designed in the 1960s.
Some of the largest and longest institutions are going in on AI.
And is exactly my point that these comments are coming from that these companies are going in on AI when some people think its not ready yet. My point is when exactly do you define that AI is ready to be used or when should you wait. Nobody can answer that question right now and is my response to the comments we're talking from.
> The sane move in such an environment is to wait and let other people leeroy jenkins in and make mistakes, learn from their blunders, and only move once clear best practices are in place.
How we do actually know when we have reached this point, is it now? Was it 12 months ago? Will it be in 12 months time? And should you just let your competitors invest in having a go while you wait. No I don't think you can, especially if you don't have any rigor around your decision for waiting or giving it a go.
Unfortunately, time is a constraint for every company that exists, and a kinda-crappy implementation of something that's available today often beats a perfect implementation tomorrow.
Like with accelerating productivity gains, the actual wall clock start-to-end time is mostly unchanged if you wait with starting a project, you can always catch up, why does it matter if I do most of the work in the beginning of a project, or toward the end?
Changing vendors is a pain in the ass, especially in B2B. Like case in point, Confluence has been around for 20+ years and still doesn't have a working search function, and is comically useless it is at everything it does. Yet businesses all over the world are all in on that garbage.
Holy strawman batman!
Wouldn't you prefer confluence fix their search now rather than hold off until the can fix it perfectly according to your end-all-be-all spec (that'll be invalidated after 2 weeks of actual use anyway)?
What I'd preferred was if they took the time to implement it correctly from the get go. What they built instead is of no use to anyone. It's a search function in name, but it doesn't provide useful search results.
Search is hard though. From how it's behaving I think they're just sticking the data in Elasticsearch or Lucene or some such, without having done the long and arduous effort of then making it good.
Though my point is that even though confluence has a search function so broken they effectively don't have a search function, they aren't meaningfully bleeding customers over it. Business sales are incredibly sticky that way. Regardless of what pleases me as a user, Atlassian has no real incentive to fix the problem, and evidently hasn't (at least last I checked).
Which is why I consider it better to use the tools that I have today to make a feature that is good enough. Rather than cynically leaning on some vendor lock-in to hope the customers stay.
Given that you seem to consider Atlassian's software so crappy, it's a bit confusing that you bring them up as an example of good management? Your advice is basically, write crappy software and don't spend any energy improving it, until you can do so for the minimum cost.
I feel like the mandate thing is silly though. Go "all in" in the sense that you enable employees who want to use these things, but let engineers adopt at their own pace.
The proof is in their work output and overall job satisfaction.