Michael, this is probably one of my favorite pieces. Much like you, I’ve had many different careers and often have a fun, curious time trying to explain my MBA in Operations, my MS in Behavioral Science, a few teaching experiences, and a full paralegal degree. That was just my 30s—the 20s and now my 40s are a whole other animal! Somehow everything merged, makes sense, and works, but I’m the only one among my family and friends who has taken on careers like world traveling. Lol. Great piece!
Michael, I like the framework. I think I tried to create a department full of Polymaths by hiring people with many different educational and work backgrounds and having them work together on operations research problems. We learned from each other and expanded our skill sets. Thanks for the kind words. It was a pleasure working with you.
Inspirational piece! Love the transparency regarding the applications versus offer letters. It’s relatable. Grateful you’ve stayed true to self. Sounds like the payoff is worth the process 🙌
It’s been great so far but, holy hell, the application process was brutal. It was a legit black hole where I could go for hours about how bad the recruiters were.
Awesome. I like how you poked at ‘hacking life’ because that advice is almost always merely mediocre and generic. The only ‘hacks’ I’ve found work are:
Wow Michael, I am so touched and impressed by your exposition. Impressed to learn your amazing journey and accomplishments over the years! and what a pleasant surprise to learn our overlap in terms of Cyber security and the blockchain space as well - wow!
And of course, I am so touched that you decided to write this piece, and use the PolyPath categorization as a lens to talk about your own journey. It’s indeed the way I envision it as well. A PolyPath is on their way to becoming a polymath.
I thoroughly agree with what you mentioned on the limitation of general corporate environment towards actually understanding the superpowers that PolyPaths bring. That is why also I feel most PolyPaths have great agency or entrepreneurship skills. In a way they have to create what they don't see.
I don't see the different masters as different, but a function of how we observe each other. It's the human expertise categorization equivalent of phenotype and genotype. When we look at a trait, we see the trait. We have no idea what code is running underneath to generate it.
When we attempt to categorize others the only data we have is phenotypic, but the rationale underneath could be completely coherent just a layer further down.
I've been exploring this with the term "source code" to strip away the armor of a title that we use as our identity, trying to get folks to see who they are.
I'm sure you've experienced this, where the are two people who hold a similar title in an identical domain, an engineer, teacher, salesperson, but the reason they are great and personally aligned to that role is completely different.
The benefit of polypaths is that it's though those various experiences that even we gain the data to interpret the underlying pattern of who we are.
I think that’s a great framing and I’ve also been playing with ‘source code.’ I’ve got an essay coming out soon on ‘The Two Rules for Life’ that, fundamentally, I view as elements of the source code.
I like the differentiation into types of polypaths. I'm very much the parallel path one. I did systems engineering at Goddard and then at Ball Aerospace where I focused on Earth remote sensing missions, eventually spending my time as the Chief Engineer. In parallel, I write fantasy fiction. These days, having retired from aerospace, I'm doing family stuff and occasionally posting here.
I didn't go as broadly as you have done. I had exactly two employers in 31 years. But I went deep into what I did. Systems Engineering for me was more than process (which I'd mastered and taught my team) but the true "if we change this electrical component here, how does it affect the thermal performance over there?" type domain knowledge.
That’s awesome. In my case, as you’ve seen over the years, I didn’t parallel my writing. It’s a phase shift at times, but my science fiction is very much impacted by my technical background.
And I like how you described the systems implications. It’s interesting, I’m a level above that, focusing more on the mission systems, human systems, and operational systems so that the design systems folks can dig in. I’d love to get down to the thermal implications of electrical changes but I’m trying to get people to follow the SEMP so we even know the change is happening!
SEMPs did not exist when I started as a Systems Engineer. We were creating the processes of systems engineering at the same time we were trying to design hardware. So I wrote one of the first SEMPs for the company before NASA ever required them. Requirements data management software showed up when I was on my second program and was so new that our programs regularly messed up setting up the databases.
So, yeah, I brought the processes into my team that you now know as the discipline of Systems Engineering, but along the way I focused on really understanding all the technical details.
As I regularly told my staff: your job as a systems engineer is not to manage the paperwork. Your job is to understand the system well enough to know if it’s going to work. That means that you need to understand electrical engineering well enough to know when the electrical engineer is trying to fudge or bullshit. You need to know mechanical engineering well enough to be able to sanity check their results. You need to have enough depth in every discipline to understand what’s going on.
The paperwork and requirements management and sell-off is a burden that we have to deal with, but it’s no substitution for understanding the actual physics of what we do.
As for my fiction, I don’t write hard sci fi because it’s too close to what I had to do daily. But I do bring scientific rigor to my fantasy.
Yeah, the paperwork is bullshit but the management processes are not. That’s the challenge is forcing check-points that enforce a full system view vs. myopy without becoming BS process checks. That’s where the Systems Engineering, Integration, and Test (SEIT) can help manage the design. A small team of systems thinkings just doing macro/micro zooming.
Michael, this is probably one of my favorite pieces. Much like you, I’ve had many different careers and often have a fun, curious time trying to explain my MBA in Operations, my MS in Behavioral Science, a few teaching experiences, and a full paralegal degree. That was just my 30s—the 20s and now my 40s are a whole other animal! Somehow everything merged, makes sense, and works, but I’m the only one among my family and friends who has taken on careers like world traveling. Lol. Great piece!
Awesome. It’s no wonder we’re in each other’s brain space so much!
That’s what I said to myself reading this piece!
Michael, I like the framework. I think I tried to create a department full of Polymaths by hiring people with many different educational and work backgrounds and having them work together on operations research problems. We learned from each other and expanded our skill sets. Thanks for the kind words. It was a pleasure working with you.
You did a great job! Definitely someone to live up to.
Stay calm and connect the dots. —GCG
Nice
Inspirational piece! Love the transparency regarding the applications versus offer letters. It’s relatable. Grateful you’ve stayed true to self. Sounds like the payoff is worth the process 🙌
It’s been great so far but, holy hell, the application process was brutal. It was a legit black hole where I could go for hours about how bad the recruiters were.
I feel you 🤜. Your experience runs counter to the popular cultural tide of hacking life and shortcuts. Keeping it real 💯
Awesome. I like how you poked at ‘hacking life’ because that advice is almost always merely mediocre and generic. The only ‘hacks’ I’ve found work are:
Insatiable Curiosity
Humility
Intentional Reframing
Love this, a full spectrum human being is one that follows their curiosity!!
Exactly right on curiosity too! That’s how I frame the core of polymathic/systems thinking.
Insatiable Curiosity
Humility
Intentional Reframing to see if I fully understand the situation.
🙌
Wow Michael, I am so touched and impressed by your exposition. Impressed to learn your amazing journey and accomplishments over the years! and what a pleasant surprise to learn our overlap in terms of Cyber security and the blockchain space as well - wow!
And of course, I am so touched that you decided to write this piece, and use the PolyPath categorization as a lens to talk about your own journey. It’s indeed the way I envision it as well. A PolyPath is on their way to becoming a polymath.
I thoroughly agree with what you mentioned on the limitation of general corporate environment towards actually understanding the superpowers that PolyPaths bring. That is why also I feel most PolyPaths have great agency or entrepreneurship skills. In a way they have to create what they don't see.
It’s a great way to think about it and perhaps, that will make more sense in Corporate America…. I doubt it but I can hope!
I don't see the different masters as different, but a function of how we observe each other. It's the human expertise categorization equivalent of phenotype and genotype. When we look at a trait, we see the trait. We have no idea what code is running underneath to generate it.
When we attempt to categorize others the only data we have is phenotypic, but the rationale underneath could be completely coherent just a layer further down.
I've been exploring this with the term "source code" to strip away the armor of a title that we use as our identity, trying to get folks to see who they are.
I'm sure you've experienced this, where the are two people who hold a similar title in an identical domain, an engineer, teacher, salesperson, but the reason they are great and personally aligned to that role is completely different.
The benefit of polypaths is that it's though those various experiences that even we gain the data to interpret the underlying pattern of who we are.
I think that’s a great framing and I’ve also been playing with ‘source code.’ I’ve got an essay coming out soon on ‘The Two Rules for Life’ that, fundamentally, I view as elements of the source code.
I like the differentiation into types of polypaths. I'm very much the parallel path one. I did systems engineering at Goddard and then at Ball Aerospace where I focused on Earth remote sensing missions, eventually spending my time as the Chief Engineer. In parallel, I write fantasy fiction. These days, having retired from aerospace, I'm doing family stuff and occasionally posting here.
I didn't go as broadly as you have done. I had exactly two employers in 31 years. But I went deep into what I did. Systems Engineering for me was more than process (which I'd mastered and taught my team) but the true "if we change this electrical component here, how does it affect the thermal performance over there?" type domain knowledge.
That’s awesome. In my case, as you’ve seen over the years, I didn’t parallel my writing. It’s a phase shift at times, but my science fiction is very much impacted by my technical background.
And I like how you described the systems implications. It’s interesting, I’m a level above that, focusing more on the mission systems, human systems, and operational systems so that the design systems folks can dig in. I’d love to get down to the thermal implications of electrical changes but I’m trying to get people to follow the SEMP so we even know the change is happening!
Ah, the age difference. ;-)
SEMPs did not exist when I started as a Systems Engineer. We were creating the processes of systems engineering at the same time we were trying to design hardware. So I wrote one of the first SEMPs for the company before NASA ever required them. Requirements data management software showed up when I was on my second program and was so new that our programs regularly messed up setting up the databases.
So, yeah, I brought the processes into my team that you now know as the discipline of Systems Engineering, but along the way I focused on really understanding all the technical details.
As I regularly told my staff: your job as a systems engineer is not to manage the paperwork. Your job is to understand the system well enough to know if it’s going to work. That means that you need to understand electrical engineering well enough to know when the electrical engineer is trying to fudge or bullshit. You need to know mechanical engineering well enough to be able to sanity check their results. You need to have enough depth in every discipline to understand what’s going on.
The paperwork and requirements management and sell-off is a burden that we have to deal with, but it’s no substitution for understanding the actual physics of what we do.
As for my fiction, I don’t write hard sci fi because it’s too close to what I had to do daily. But I do bring scientific rigor to my fantasy.
Yeah, the paperwork is bullshit but the management processes are not. That’s the challenge is forcing check-points that enforce a full system view vs. myopy without becoming BS process checks. That’s where the Systems Engineering, Integration, and Test (SEIT) can help manage the design. A small team of systems thinkings just doing macro/micro zooming.
Thank you for sharing your experience. As a fellow Polly-Path taker, I can heavily relate.
It’s an adventure for sure!
Excellent advice! Thankfully my career has been varied as well. Certianly not boring. Now I have a great term to describe it.
Great to hear!
Damn… this only further expands how interesting you are brother.
Lol. It's crazy.