Principles of Paranoia : Engineering Insights
This post was originally written here and got bookmarked over 500 times, way more than I expected.
For the engineers who wanna build physical things at a large scale in the USA (not using pension money or gov't or VC money)/ ie - being resourceful, here's some brouhaha for ya......
For everyone else, this will put you to sleep........
I have had the privilege of working with squadrons of operations research, applied math, and materials engineering PHDs and more.
I'm one of 60 engineers on the planet trained in my specialty (operations research + polymer eng.), 1 of 20 in the USA, and 1 of 3 that has designed, scaled, and optimized 100M+ tonne systems multiple times over.
My predecessors in some of the companies were ex-CIA and some advised congress on issues related to nat sec. Learned a lot from them.
Things to know/learn/be cognizant of:
1) Objective Functions - declare a specific objective(https://byjus.com/question-answer/what-is-the-objective-function-in-linear-programming-problems/#:~:text=The%20real%2Dvalued%20function%20whose,are%20constraints%20and%20are%20variables….)
2) Constraints (https://leanproduction.com/theory-of-constraints/…)
3) How do you measure reality? (read the book "A measure of reality")
4) Local operating environment variables -- you will always unravel the taxonomy and schema of both competitors benchmarking and the environments themselves iteratively. ie leave room to add more columns of data to your modeling and repeat til you have a full picture of the data model and operating environment.
5) Model for weather, breaks in transportation, and feedstock volatility. (Example, I designed a facility that utilized liquid nitrogen to make a byproduct of a polymer --- the O&G prices and futures and quantity I could buy in influenced the viability of the overall polymer's end use case)
6) "Only the paranoid survive." - You need to have a working memory of thousands of real world technologies and a benchmark of their EROI (Energy return on investment)
7) Always, always, talk to the people on the front lines and incentivize their participation in the outcome. Your models will improve.
8) Test your CFO on combinatorics and prob/stat - figure out of they're a glorified bookkeeper or an actual wrangler. (Can they do regressions?) etc..
9) Deduce the cost of the Bill of Materials and its supply chain not in terms of dollar costs, but in terms of kilowatt hours - this gives you negotiating room with suppliers and service vendors as you can deduce their relative hard costs. Track back to costs. You'll have to put elbow grease into looking up prices on electricity across your forecasted locations in the supply chain. This one thing will give you a basis of measurement that others cannot wrangle.
10) Model feedstock volatility against the Federal Stress Indexes on the dollar.
11) Understanding feedstock volatilities will take you a lifetime, but you need to with relative certainty have low, medium, or high conviction and know where you sit in that chain.
12) Getting verbally violent pseudorandomly with suppliers when all things are calm will prevent headaches in the future. Keep them active, they will get lazy. This is the annoying cost of doing business. Also monitor their churn.
13) If a vendor is telling you that a machine has a max throughput, they're probably lying to you.
14) Throw anyone out of your org if they call themselves a polymath or obsess over the notion of IQ.
15) An engineer who does not break bread with their technicians or doesn't know them well enough is a recipe for danger int he facility, fix immediately.
16) if you want data across the org, assume you'll need a political or violent (not physically) trojan horse to obtain it.
17) if a data request takes longer than 3 days, then the org has to be ripped apart and fixed from the silicon up so to speak.
For the engineers who wanna build physical things at a large scale in the USA (not using pension money or gov't or VC money)/ ie - being resourceful, here's some brouhaha for ya......
For everyone else, this will put you to sleep........
I have had the privilege of working with squadrons of operations research, applied math, and materials engineering PHDs and more.
I'm one of 60 engineers on the planet trained in my specialty (operations research + polymer eng.), 1 of 20 in the USA, and 1 of 3 that has designed, scaled, and optimized 100M+ tonne systems multiple times over.
My predecessors in some of the companies were ex-CIA and some advised congress on issues related to nat sec. Learned a lot from them.
Things to know/learn/be cognizant of:
1) Objective Functions - declare a specific objective(https://byjus.com/question-answer/what-is-the-objective-function-in-linear-programming-problems/#:~:text=The%20real%2Dvalued%20function%20whose,are%20constraints%20and%20are%20variables….)
2) Constraints (https://leanproduction.com/theory-of-constraints/…)
3) How do you measure reality? (read the book "A measure of reality")
4) Local operating environment variables -- you will always unravel the taxonomy and schema of both competitors benchmarking and the environments themselves iteratively. ie leave room to add more columns of data to your modeling and repeat til you have a full picture of the data model and operating environment.
5) Model for weather, breaks in transportation, and feedstock volatility. (Example, I designed a facility that utilized liquid nitrogen to make a byproduct of a polymer --- the O&G prices and futures and quantity I could buy in influenced the viability of the overall polymer's end use case)
6) "Only the paranoid survive." - You need to have a working memory of thousands of real world technologies and a benchmark of their EROI (Energy return on investment)
7) Always, always, talk to the people on the front lines and incentivize their participation in the outcome. Your models will improve.
8) Test your CFO on combinatorics and prob/stat - figure out of they're a glorified bookkeeper or an actual wrangler. (Can they do regressions?) etc..
9) Deduce the cost of the Bill of Materials and its supply chain not in terms of dollar costs, but in terms of kilowatt hours - this gives you negotiating room with suppliers and service vendors as you can deduce their relative hard costs. Track back to costs. You'll have to put elbow grease into looking up prices on electricity across your forecasted locations in the supply chain. This one thing will give you a basis of measurement that others cannot wrangle.
10) Model feedstock volatility against the Federal Stress Indexes on the dollar.
11) Understanding feedstock volatilities will take you a lifetime, but you need to with relative certainty have low, medium, or high conviction and know where you sit in that chain.
12) Getting verbally violent pseudorandomly with suppliers when all things are calm will prevent headaches in the future. Keep them active, they will get lazy. This is the annoying cost of doing business. Also monitor their churn.
13) If a vendor is telling you that a machine has a max throughput, they're probably lying to you.
14) Throw anyone out of your org if they call themselves a polymath or obsess over the notion of IQ.
15) An engineer who does not break bread with their technicians or doesn't know them well enough is a recipe for danger int he facility, fix immediately.
16) if you want data across the org, assume you'll need a political or violent (not physically) trojan horse to obtain it.
17) if a data request takes longer than 3 days, then the org has to be ripped apart and fixed from the silicon up so to speak.