This is rule 5 of Bill’s 7. This seems applicable to our more mundane automation of our applications and workflows.
Many companies are throwing AI and automation at broken processes. Gates warns: Fix your process first, then automate it. Otherwise you’re just creating faster chaos.
According to a 2025 survey by S&P Global Market Intelligence, 46% of AI proof-of-concepts were scrapped prior to production.
"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency,” Gates said in The Road Ahead. “The second is that automation applied to an inefficient operation will magnify the inefficiency.”
Thanks for sharing this. I also like the #4, with the wisdom of age (and being a billionaire, I suppose):
4. Give yourself grace
“You are not a slacker if you’ve cut yourself some slack,” Gates said in a 2023 commencement address at Northern Arizona University. “It took me a long time to learn [that].”
The same man who used to spy on employees by memorizing their license plates and watching who was and who wasn’t putting in hustle hours at Microsoft in the early years has evolved into a vocal advocate for self-compassion and caring leadership.
I had this argument with a senior manager just recently that our company switching to Agile many years ago addressed the symptom, not the cause. The waterfall development model works OK if you are honest with yourself.
A supposed mantra of agile is “move fast and break things”. This was a great advancement on “Move slow and break things.” We still break things and, sure, we may fix them faster, but then we’re just able to move onto the next break sooner. The problem is why do we break things?
Actually, it has nothing to do with agile, but rather with how start-ups commonly run. The Agile Manifesto’s second value specifically emphasises “Working software over comprehensive documentation”. The principles also center around robust quality and collaboration among stakeholders.
I agree that waterfall can also work, but the main problem is that we then treat development of core support systems as a project, usually with no long term plan for how to run and maintain it over time. Project metrics like “on time and budget” takes precedence over “working software” designed for long-term maintainabiliity and stability.
Projects have an end-date. The delilvered solution doesn’t. If you build a good system, it can easily live for 15-20 years or more.
The speed in agile does not come from working in “sprints” - it comes from a close enough collaboration with the users/stakeholders to build the thing that meets their use cases. Fast feedback is where speed is essential. Speed in delivery is a side effect of close collaboration and focus on technical excellence.
…but granted, that is now how most agile teams are set up.
One of the big challenges in developing software is anticipating what will be necessary down the road. People, in general, are very bad at that. But giving them some working software and letting them use it will surface use cases that would not have been anticipated ahead of time.
There’s a big difference between broken and inefficient. If you need sliced tomatoes in a restaurant, a process that regularly produces sliced bell pepper is fundamentally broken. Making that process faster will produce bigger and bigger piles of sliced bell pepper.
But a process where somebody cuts every slice by hand, rather than using a tomato slicer, is just inefficient. Sometimes speeding up an inefficient process is all you need to achieve success.
In the real world, I don’t think it’s “fix your process, then automate” vs. “automate, then fix your process.” It’s cyclical.
The single biggest benefit I’ve found to automating is that it forces you to get clear about the process. It’s not at all uncommon to say “we have a process,” and then discover that there are numerous real-world variations regarding how things are executed. The process of pinning down “how things are done” is kind of like trying to teach something to somebody else, and realizing that you don’t completely understand it yourself.
Automating a process - even if it’s not ideal - can produce standardization. And then once it’s standardized, it can be optimized.
Definitions and practice are two things that should be the same. But I see exactly this same problem in an agile organisation. I think, perhaps, agile works best without large amounts of complexity.
As someone who has read the Agile Manifesto (go read it, it’s short) and who has taken Agile training courses (I’m Certified!) you are of course technically correct.
The problem is that language is not precise and the meaning of a word is largely based on common usage. And all too often, the meaning in the sense that @zkarj is using is the one that “upper management” (and often lower management (is middle management still a thing?)) uses. And no amount of pointing out this misusage will change anything. *
Regardless of the methodology used, the main issues I have encountered over my career have been:
Incomplete/inaccurate requirements (that’s what we asked for but not what we want).
Inadequate resources (time, money, people, pick any three).
Unrealistic timelines (especially onerous is when an exact date is specified prior to project initiation.)
In my experience, Agile is just another in a long line of “silver bullets” (high level languages; object oriented programming; the capability maturing model; write once - run everywhere; and the current darling - vibe coding) that upper management believes will solve all development problems. All are useful tools, none eliminate actually doing the work (and just to be clear, none made this claim).
* in my last job we did waterfall and called it agile (because we had sprints!). I started calling it “agilefall” as my attempts to point out the misuse got me nowhere.
For the last 20+ years of my life I’ve helped teams be more effective. It is my whole business.
Agile done well is like magic. The magic isn’t “Agile” the magic is that we help a group of people work together to build a better product through collaboration and with clear feedback from the client.
Imposed Agile i.e. management force it down your throat, rarely has a good effect.
Ceremonial Agile - we hold the events but without putting in the improvement effort is only ok.
At this stage my business is increasingly focused on taking Imposed or Ceremonial Agile and helping people make the magic happen.
Fun story. At a local “agile” company, management decided they wanted to incentivize the coders’ productivity.
Management apparently didn’t quite “get” how agile worked, and decided that they would incentivize “the team that had the most points at the end of the month.” You know, the “points” that get assigned to various features, based on anticipated effort?
They apparently primarily succeeded in incentivizing their teams to assign comically huge numbers of points as the baseline. “Fixing these typos on this one page is 10 million points. Building the login screen is 1 billion points.”
This is an ongoing joke for me in workshops. I show people, you get exactly what you measure. If measure Nebulous Units of Time (aka Story Points) then you will get many many NUTs.
