(1) Intellectual curiosity (2) Big picture view (3) Connections (4) Comfortable with change (5) Comfortable with uncertainty (6) Proper paranoia (7) Resources + Margins (8) Communication skills (9) Self confidence + Energy (10) Appreciation for the process *Bonus* Commission not omission - don't wait for someone to tell you what to do and track, take the initiative and wait to be told to stop
Excellent introduction by the First Gentleman, it’s takes courage to keep going when you stutter. Kudos to the audience as well for cracking a few jokes, to keep the air light and possibly not as imposing as the gentleman gave an to the speaker, who gave an great presentation.
This lecture is so fucking good it's unreal. This is what I love about systems engineering: "the partial of everything with respect to everything." For most people, education is a narrowing process, you slowly specialize, alienating yourself from everyone that isn't working on your niche subject so that, eventually you become master of the world's smallest perspective! You become expert of the world's tiniest field, compelling right? Eventually, at a certain point into your PhD, you finally realize that you can no longer coherently answer the question, "what is it that you're studying?" when out on a date. You can't even communicate what it is that you spend half of your waking hours doing. You have to resort to complicated jargon because you don't understand the bigger picture, you have to be esoterically technical because for you there is no wider generality that other people can relate to, and just think about how lonely that life is, just think about it. You eventually become that sort of amateur astronomer that only knows about the star tracker. You don't know about attitude control or Kalman filters, you don't know that everything feeds back into everything else, so you spend your days in a sort of cozy somber sliver of reality. Every once in a while, a system's engineer comes shining into your dark den and asks you (yes you alone, his pathetic subject, a tiny shadow which has taken refuge at the furthest distance from the imperial sun) a question, and you obsequiously respond in your obscure moon language and you (forever circumscribed by the greater reality) sit and wonder.
It's very true that PhD. is actually blocking you from seeing the big picture . But at the same time touching everything doesn't give you the details . And if you don't apply first rule of thinking and breaking down the system into details and understand the core principles of how they made it will be difficult to have a better definition of your system. So, although you have a perspective that suits you to appreciate what you are doing and what you want to persuade for the future, you always need PhD level details to build a system from bottom up. So, the system and PhDs are equally needed to have a better system
*Thank You So Much* 😊❤ This is so encouraging: after decades of doing systems engineering & architecture as part of my very successful software and hardware engineering efforts, in the last couple years I have been easing into systems engineering officially. YET as an autodidact, I know there are many holes in my knowlege and experience, BUT it is most validating that I have all these important characteristics in spades!! Now I am filling-in the process pieces in formal ways that I never needed (nor was exposed to) in my smaller efforts in private industry. Talks like this give me context, validation, and encouragment as I move forward. 😊
IMO V model is broken. It tries to be linear/waterfall but actually degrades into iterative by connecting the top of the V with the esoteric "Validation" backpropagating through the V to the original requirements. This builds up floating-requirement-error that eats away unnecessarily at margins (requirements must be within capability and the gap between those circles is that floating requirement error). Being agile and defining interfaces between systems rather than constraining the input/output of each system would allow for early testing to determine which system has more slack/can achieve tighter requirements towards the objective. This would result in a distillation of our concepts based on the available low level requirements and then we'd kinda meet in the middle where high-level concept meets requirements. Not sure how Validation would be solved but I feel like it may occur at that point where the two meet (earlier than in the V model). It would mean that trade studies and concepts would be less influential over requirements and we could be more operationally inclined like an industrial engineer. I rhetorically ask: If us systems engineers are doing non-linear optimization, why are we trying to linearize the process just for operations to try and parallelize & change schedule?
(1) Intellectual curiosity
(2) Big picture view
(3) Connections
(4) Comfortable with change
(5) Comfortable with uncertainty
(6) Proper paranoia
(7) Resources + Margins
(8) Communication skills
(9) Self confidence + Energy
(10) Appreciation for the process
*Bonus*
Commission not omission - don't wait for someone to tell you what to do and track, take the initiative and wait to be told to stop
Thank you very much
Excellent introduction by the First Gentleman, it’s takes courage to keep going when you stutter. Kudos to the audience as well for cracking a few jokes, to keep the air light and possibly not as imposing as the gentleman gave an to the speaker, who gave an great presentation.
This lecture is so fucking good it's unreal. This is what I love about systems engineering: "the partial of everything with respect to everything." For most people, education is a narrowing process, you slowly specialize, alienating yourself from everyone that isn't working on your niche subject so that, eventually you become master of the world's smallest perspective! You become expert of the world's tiniest field, compelling right? Eventually, at a certain point into your PhD, you finally realize that you can no longer coherently answer the question, "what is it that you're studying?" when out on a date. You can't even communicate what it is that you spend half of your waking hours doing. You have to resort to complicated jargon because you don't understand the bigger picture, you have to be esoterically technical because for you there is no wider generality that other people can relate to, and just think about how lonely that life is, just think about it. You eventually become that sort of amateur astronomer that only knows about the star tracker. You don't know about attitude control or Kalman filters, you don't know that everything feeds back into everything else, so you spend your days in a sort of cozy somber sliver of reality. Every once in a while, a system's engineer comes shining into your dark den and asks you (yes you alone, his pathetic subject, a tiny shadow which has taken refuge at the furthest distance from the imperial sun) a question, and you obsequiously respond in your obscure moon language and you (forever circumscribed by the greater reality) sit and wonder.
Damn 😂😂
Damn, is there a way of connecting with you? I am an aerospace engineer trying to gain perspectives on systems engineering.
Too good.
Lol great comment
It's very true that PhD. is actually blocking you from seeing the big picture . But at the same time touching everything doesn't give you the details . And if you don't apply first rule of thinking and breaking down the system into details and understand the core principles of how they made it will be difficult to have a better definition of your system.
So, although you have a perspective that suits you to appreciate what you are doing and what you want to persuade for the future, you always need PhD level details to build a system from bottom up.
So, the system and PhDs are equally needed to have a better system
I keep finding myself watching this lecture from time to time. This is really the best Systems engineering talk
May I know where you are working as SE currently?
Me too
You still a SE?
So surreal to hear him saying "email is not a substitution for face to face communication." While being stuck in Covid quarantine through 2020-2021
*Thank You So Much* 😊❤
This is so encouraging: after decades of doing systems engineering & architecture as part of my very successful software and hardware engineering efforts, in the last couple years I have been easing into systems engineering officially. YET as an autodidact, I know there are many holes in my knowlege and experience, BUT it is most validating that I have all these important characteristics in spades!! Now I am filling-in the process pieces in formal ways that I never needed (nor was exposed to) in my smaller efforts in private industry.
Talks like this give me context, validation, and encouragment as I move forward. 😊
So true, commission and not omission against all odds. Thanks, Gentry for the heads up!
Excellent talk.
Great lecture!. Thanks for uploading it!
This lecture was recorded some time in 2005.
Great Lecture. Thank you very much for sharing.
so basically SE is the god that must know everything and what's going on in the project?
Yes
yes
And it's a group effort. There should not be only one, but a team of them
He might not know everything he needs to depend on SMEs but he should know what's going on the project.
Wow what an awesome lecture
Best thing in the history of all time
Great lecture!..thanks for sharing!
Awesome. Thanks for sharing!
I think ive been inspired in a new direction...
me too
Can some kind soul type out the list for later reference?
IMO V model is broken. It tries to be linear/waterfall but actually degrades into iterative by connecting the top of the V with the esoteric "Validation" backpropagating through the V to the original requirements. This builds up floating-requirement-error that eats away unnecessarily at margins (requirements must be within capability and the gap between those circles is that floating requirement error).
Being agile and defining interfaces between systems rather than constraining the input/output of each system would allow for early testing to determine which system has more slack/can achieve tighter requirements towards the objective. This would result in a distillation of our concepts based on the available low level requirements and then we'd kinda meet in the middle where high-level concept meets requirements. Not sure how Validation would be solved but I feel like it may occur at that point where the two meet (earlier than in the V model). It would mean that trade studies and concepts would be less influential over requirements and we could be more operationally inclined like an industrial engineer.
I rhetorically ask: If us systems engineers are doing non-linear optimization, why are we trying to linearize the process just for operations to try and parallelize & change schedule?
Can Gentry talk to us about dBase?
Love this lecture
Geddy Lee's brother. Love Jewish humor.
28:08~32:30: proper paranoia
why the hell