3 ms·
This has always been a balancing act. I was an engineering manager for 25 years, and had to deal with the balance. I worked for a heavily process-driven compan
by ChrisMarshallNY 1y ago
This has always been a balancing act.
I was an engineering manager for 25 years, and had to deal with the balance. I worked for a heavily process-driven company. It could be infuriating, but they did manage to consistently produce some of the finest hardware in the world (unfortunately, the same could not be said for the software).
I have found that writing things down, can ossify a project, but you really can't do without. Communication overhead is the single biggest killer. That's why a small team of experienced engineers, that are used to working together, can often do amazing amounts of work, and that "tribal knowledge" -that bugaboo of software process gurus- is actually a very important accelerator.
I wrote a post called "Concrete Galoshes"[0], that talks about the things that add structure and inflexibility to projects.
The single biggest lesson, is that we should be very careful about "One Size Fits All" solutions. Different types of projects need different types of overhead and structure.
[0] https://littlegreenviper.com/various/concrete-galoshes/ https://littlegreenviper.com/various/concrete-galoshes/
- frutiger 1y ago[flagged]
- deleted 1y ago[deleted]
- jaggederest 1y agoChris Marshall lists substantial time at Nikon on his LinkedIn. I suspect you've probably heard of them.
- ChrisMarshallNY 1y agoI generally don’t name them, in my posts, in order to reduce the amount of “media noise” they need to search through. Also, I will occasionally say less-than-complimentary stuff about them (not too bad, I still have massive respect for them). I’d rather not give them agita.
- deleted 1y ago[deleted]
- frutiger 1y agoIt was a very pretentious thing to say. Either mention the company Or don’t mention the status of the company at all. Leaving readers wondering or hanging is eyeroll-inducing.
- ValueForCash 1y agoHis name is right there. If you are upset by it then spend 15s on Google.
- frutiger 1y agoI did, and this is what I got https://www.joinlavender.com/chris-marshall-ny https://www.joinlavender.com/chris-marshall-ny
- AdieuToLogic 1y ago> Communication overhead is the single biggest killer. True. To put a fine point on this I would add that enabling requisite communication is an exponential equation. Specifically, adding team members typically increases intra-team communication requirements exponentially as does adding teams to the organization. > That's why a small team of experienced engineers, that are used to working together, can often do amazing amounts of work, and that "tribal knowledge" -that bugaboo of software process gurus- is actually a very important accelerator. I believe both situations you have identified are derived from the same concepts - trust and understanding. Trust, in that small experienced teams who have worked together for a nontrivial period of time learn in which areas each excel and where they do not. Understanding, in that those highly effective teams value the trust established and seek to complement each other's skills. I believe "tribal knowledge" should be an expected product of the above and is ideally captured via documentation, mentoring, presentations, etc.
- bonoboTP 1y agoMaybe it's implicit, but you didn't mention why process-people hate illegible tribal knowledge. It's because they fear that the people may have better leverage in salary re-negotiation, and if they bail, the knowledge disappears. They want exchangeable engineers as the article writes. And in a way, becoming more standardized and less unique (at least in the minds of managers) is beneficial to oil the machine of the job market and economy. Ineffective companies can be left quickly, highly profitable companies can grow more easily. More abstractly, explicit rules are a substitute for trust. You can run your family or friend group without coming up with a literal rulebook, but this already fails in a bigger village. So you first get mythical oral religious laws, then city-state laws etc. It's always a trust-substitute. But that's the only way to scale to civilization from distributed tribal lifestyle.
- AdieuToLogic 1y ago> Maybe it's implicit, but you didn't mention why process-people hate illegible tribal knowledge. It's because they fear that the people may have better leverage in salary re-negotiation, and if they bail, the knowledge disappears. Being at a disadvantage in annual reviews is certainly a part of it I'm sure. Another non-trivial risk an organization must manage is retaining knowledge in a shareable form should team members transfer to other groups, take on a new role within the organization, or leave for reasons other than failed salary negotiations. > More abstractly, explicit rules are a substitute for trust. This is an interesting concept, thank you for sharing it (seriously). Stating it the way you have succinctly explains some of the asinine policies I have experienced in the past. Usually in large, dysfunctional, organizations I might add.