I think you're both in agreement. I believe the point about tools was not to enshrine any particular tool, but rather, to create a culture where internal tools are viewed as being the most important technical contribution.
This is backwards from many technology companies where internal tooling is often given a lower priority and the work assigned to less skilled engineers. This is often done with noble intent, like to try to create the best value possible for customers via improving customer facing features. But I think that proves a short term strategy rather than focusing on enabling your organization as a whole. You'd be surprised how many resources become free for feature work when your tools and infrastructure are so good that you don't wast effort on what could be automated or prevented.
This comment is correct. My intention is not to prioritize tools over thinking about anything else. If you read the essay linked from it, I said "your most talented engineers should be working on your tools." So when I say "highest priority," I mean development priority, i.e. you shouldn't have your best people working on features and your second-tier people doing tool work, like many organizations do.
You might like to short-circuit a lot of this learning.
There was a fighter pilot who studied this for 40 years named John Boyd. He architected the f15, 16, 18, A-10 and the first iraq invasion. His academic work short circuits what all the dotcoms (including facebook) are slowly learning through trial and error.
If you want a starting place Robert corams book on boyd is excellent, while Frans Osinga's thesis Science, strategy and war is essential reading for the hard subject matter.
Sorry I responded too quickly.
People,
Ideas,
Hardware (technology)
In that order are what you should focus. Near 100% of managements time should be spent on people and ideas. Get that right and the people will take care of the technology.
One tool to implement that is a mission order (No civilian counterpart), which is where you define an intent to be achieved and operating parameters to be met but not how that intent is to be carried out. parameters are mutually agreed on - and the subordinate has the right to refuse. Usually you leave most of the definition of the intent up to the subordinate. Like "build a database useful for storing graph data" or "Find a way to improve ads customer acquisition".
EFAS culture - An implementation of blitzkrieg for business gleaned from interviews done in the 70's implements this nicely.
This is backwards from many technology companies where internal tooling is often given a lower priority and the work assigned to less skilled engineers. This is often done with noble intent, like to try to create the best value possible for customers via improving customer facing features. But I think that proves a short term strategy rather than focusing on enabling your organization as a whole. You'd be surprised how many resources become free for feature work when your tools and infrastructure are so good that you don't wast effort on what could be automated or prevented.