This is also why all of these companies invest colossal amounts of effort into Scrum/SAFe (Scaled Agile for Enterprise, one of the biggest tech oxymorons, just imagine being "agile" following this process). "Doing Scrum by the book" is considered more valuable than "making shit that works."
Most of this, in fairness, is because the driving factor for many very large businesses is not innovation; it's avoiding fuckups that incur big liabilities. Which trickles down to the management as process-following, because as long as you're following the process than any errors are S.E.P.
Oh yeah I wrote about that a while back (as an aside, I need to fragment these articles into the individual ideas so I can link to them more efficiently) "Data driven" inevitably means "cherry picking the data that fits established knowledge" exactly because that comes with insurance.
"but why can't small companies make good software then?" because the majority of small companies are started by either big tech alumni, or kids who emulate them. they blindly copy both the tech stack (no your website doesn't need React) and the org design because they think it's Best Practices.
I've yelled about Best Practices before and will continue to do so now The thing about a Practice is that it's a tool - it helps you do a thing. It will be better at achieving some goals and worse at achieving others, so you need to pick your goal FIRST and only then pick the Practices to reach it.
My experience of "Best Practice" is that it is an execution instead of a strategy. It's far more about familiarity with that practice than that practice being provably "best" in any way. I like asking the devs why React, Angular, etc early on. It's ALWAYS familiarity and not a technical reason.
A practice may be Best to reach one goal over another, or in one context over another. What the legion of Thought Thinkers in tech proclaims when they nominate a Best Practice is "these goals are the goals you should have, these contexts are the contexts you should create."
If you pick up bundles of Best Practices like 36-packs of canned tuna at Costco, you don't get the opportunity to set your own goals. The system you just adopted will incentivize its own goals; it will make it easier to do the things the system was designed for, so those things will get done.
No one loves this outcome more than Nothing Managers, because it relieves them of having to think. It's much easier to govern the adoption of Best Practices than to figure out what you want to achieve and how you are going to achieve it. Throw the book at your people, and go for lunch.
This works best when your manager is also a Nothing Manager (most of the time!) and has no way to evaluate whether your strategy is creating value Adopting Best Practices is a self-contained outcome. We are adopting Best Practices so that we can have a Best Practices org. The value* is obvious**!
If it's not working, you don't have to trouble your brain; Best Practices are interoperable so you can always find a coach/consultant/course that will help you Practice them More Better. Of course, just like metrics, the usefulness of a practice is inversely proportional to its universality.
None of this is new, of course. David Noble called it out in 1995: the first priority of managers is job security, not productivity.
💯☝️
Sociologists DiMaggio & Powell called the process you're talking about "institutional isomorphism" and claimed that orgs copy each other because when they need to decide something and don't know how, they look to another org and assume (probably wrongly) they had a good reason for doing it that way.
ooh “institutional isomorphism” is a fun one, adding that to my collection
Peter Drucker, on managers (1955): "It always requires twice as much effort and skill to stay up as it did to climb up." The managers put their considerable efforts into staying in place.
Also, a best practice is now considered one because of years of proof that it works. The problem with that is that the context changed during those years, which makes that best practice less relevant as time goes by. Applying it as is is just digging your own grave, you should always look further.
Reminds me of @bretdevereaux.bsky.social's piece on ancient religion - the rituals were that way *because they worked* and if they did not work, it must have meant that you didn't do them properly enough (or the gods are angered) rather than because the ritual did not work. Best Practices!
This makes it so much clearer! "This org is dedicated to aligning with industry-standard religious rituals until the gods smile upon us with profit"
OK. So I'm not the only one concerned with the big tuna haul mentioned earlier.
I really love this talk from @eaton.fyi called "The Doctrine Gap" because I think it clearly articulates what's missing when we talk about strategy or tactics or best practices or goals or any of the other words we use to describe how a team should operate. eaton.fyi/talks/the-do...
Tired: Scrum Wired: Deep Battle
Just jumping in here to say I wish React would fuck off forever
You there! React boy!! Take this book on HTML 5 and have a read of it. You will be amazed at all the semantic elements that are NOT
👏 into 👏 the 👏 sun 👏
Not one of them has ever done Scrum by the book. The book says your teams should be self-managing. None of them have ever followed that. If the first thing you do with your new car is take the engine out, it isn’t the car’s fault that it doesn’t go anywhere.
The teams are self-managing, but naturally you need a Vanguard Party - er, I mean, Agile Coach - to make sure that the team is self-managing correctly.
It's not a good sign when the UX Designer know how to scrum better than the dev manager. In the past 7 years I've been on one team that knew how it's supposed to work & performed it well. Not by following a handful of ceremonies according to a list, but by acting in accordance with first principles.
I could excuse the Scrum master/agile coach if there wasn’t also a manager. That’s the thing about Scrum: the concept is all about the benefits of giving up control, but the only way it’s ever been implemented has begun with, “We want the benefits, but we’re not going to give up control.”
we put the delivery team inside Agile and the decision-making outside of Agile but for some reason our velocity didn't improve???
? I don't think eg Google does SAFe
The benefit of any of this being letting people create working practices, the downside is that people fixate on using process in a cargo cult approach that doesn’t facilitate shit. Obviously I have had more worse experiences than better with people who are bad at understanding those models.
And as you note with the over-large bureaucracies these intra-team cultural agreements do not scale well at all, and require active collaboration not whatever cross org zero-sum perspective infighting as happens in these lumbering companies fighting for the appearance of infinite growth.
Love the alt text on this 👏🏻