Not exactly - there are about three things in play 1. You cannot alter a company with code in the way you can with written words. If we split the compmay-as-a-

Not exactly - there are about three things in play 1. You cannot alter a company with code in the way you can with written words. If we split the compmay-as-a-machine and company-as-people-operating-(in)-the-machine and compmay-as-people-adjusting-the-machine then the difference is more stark. a company as a machine does run on written (and often unwritten) policies that humans adhere to. More and more now there is code doing the actual machine but but it is rare if ever it is a whole piece - maybe there are whole companies totally automated but so doubt it. As such a big important part of being a manager - changing the machine to be more efficient - is just not (yet) possible with code. but when it is, managers will talk code and write code. 2. I am not sure where to go with the filing part. Yes in many companies there are so many jobs to get done that anyone getting their hands in and automating anything is a huge help. That person would be making a part of the company-as-machine. good. presumably they would do it ten hours a week to a professional standard. is it the best way to organise things. No - again torvalds had hierarchical arrangement and hardly ever write code - but that belies the reams of code he wrote as examples, discussion documents, strawman and just test code. Manager should be writing test frameworks or tools to build the documentation in Japan or whatever 3. The whole "pointing people at someone else who is expert". scream bottleneck to me. Screams that people are in silos, there is not enough brown bag lunches ot other ways to discover / get repeatedly told about how other areas of codebase work. 4. things like weird bugs and effects of the tech stack are great - exactly the sort of thing to put in a code review. Or a code review of reviews (which I think is another good managerial practise)