Lian Ming Goh’s Post

SpaceX's secret weapon is it's Systems Engineering culture. The SpaceX mafia is real (Vardra, Impulse, Relativity, STOKE, Radiant, Apex) and they are taking a wildly different approach. Here's 5 lessons you can take from SpaceX: 1. Every Engineer is a Systems Engineer SpaceX doesn't have traditional systems engineers. At SpaceX, engineers are called RE's, or responsible engineers. REs are domain engineers who take a systems eng mindset - taking ownership of both design and requirements to ensure integration across teams. The core realisation here is that either everyone is a systems engineer, or no one is. 2. Fundamentally Different Collaboration Model The core principle of the iterative approach is that It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This requires a great systems team to be networked not siloed. You need REs negotiating requirements directly, fostering a deeper understanding of the entire system among all engineers, and accelerates changes and improvements. This will lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration. Teams must adapt to late-stage changes, with rework likely. Constant change is the norm… 3. Every Problem is a Systems Problem Which system/team does reusability fit in? What about self-driving/cruise control? In order to solve really hard problems, every engineer needs to put the mission first and optimise their own system second. They must be willing to make sacrifices in their area (make a worse system, or delete it) for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice. 4. Systems Engineers Are Called “Design Reliability Engineers” In a world of RE's, what becomes of the systems engineer? They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss. Systems engineers graduate from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams. 5. Rename Internal Requirements to "Design Criteria" SpaceX distinguishes external requirements from internal design criteria. Why? It's about the mindset. The terminology encourages engineers to challenge and refine internal constraints. This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity. Disclaimer: All information is public and non-confidential. This post is not affiliated with or endorsed by SpaceX.

SpaceX's secret weapon is it's Systems Engineering culture. The SpaceX mafia is real (Vardra, Impulse, Relativity, STOKE, Radiant, Apex) and they are taking a wildly different approach. Here's 5 lessons you can take from SpaceX: 1. Every Engineer is a Systems Engineer SpaceX doesn't have traditional systems engineers. At SpaceX, engineers are called RE's, or responsible engineers. REs are domain engineers who take a systems eng mindset - taking ownership of both design and requirements to ensure integration across teams. The core realisation here is that either everyone is a systems engineer, or no one is. 2. Fundamentally Different Collaboration Model The core principle of the iterative approach is that It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This requires a great systems team to be networked not siloed. You need REs negotiating requirements directly, fostering a deeper understanding of the entire system among all engineers, and accelerates changes and improvements. This will lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration. Teams must adapt to late-stage changes, with rework likely. Constant change is the norm… 3. Every Problem is a Systems Problem Which system/team does reusability fit in? What about self-driving/cruise control? In order to solve really hard problems, every engineer needs to put the mission first and optimise their own system second. They must be willing to make sacrifices in their area (make a worse system, or delete it) for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice. 4. Systems Engineers Are Called “Design Reliability Engineers” In a world of RE's, what becomes of the systems engineer? They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss. Systems engineers graduate from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams. 5. Rename Internal Requirements to "Design Criteria" SpaceX distinguishes external requirements from internal design criteria. Why? It's about the mindset. The terminology encourages engineers to challenge and refine internal constraints. This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity. Disclaimer: All information is public and non-confidential. This post is not affiliated with or endorsed by SpaceX.

SpaceX's secret weapon is it's Systems Engineering culture. The SpaceX mafia is real (Vardra, Impulse, Relativity, STOKE, Radiant, Apex) and they are taking a wildly different approach. Here's 5 lessons you can take from SpaceX: 1. Every Engineer is a Systems Engineer SpaceX doesn't have traditional systems engineers. At SpaceX, engineers are called RE's, or responsible engineers. REs are domain engineers who take a systems eng mindset - taking ownership of both design and requirements to ensure integration across teams. The core realisation here is that either everyone is a systems engineer, or no one is. 2. Fundamentally Different Collaboration Model The core principle of the iterative approach is that It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This requires a great systems team to be networked not siloed. You need REs negotiating requirements directly, fostering a deeper understanding of the entire system among all engineers, and accelerates changes and improvements. This will lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration. Teams must adapt to late-stage changes, with rework likely. Constant change is the norm… 3. Every Problem is a Systems Problem Which system/team does reusability fit in? What about self-driving/cruise control? In order to solve really hard problems, every engineer needs to put the mission first and optimise their own system second. They must be willing to make sacrifices in their area (make a worse system, or delete it) for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice. 4. Systems Engineers Are Called “Design Reliability Engineers” In a world of RE's, what becomes of the systems engineer? They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss. Systems engineers graduate from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams. 5. Rename Internal Requirements to "Design Criteria" SpaceX distinguishes external requirements from internal design criteria. Why? It's about the mindset. The terminology encourages engineers to challenge and refine internal constraints. This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity. Disclaimer: All information is public and non-confidential. This post is not affiliated with or endorsed by SpaceX.

SpaceX's secret weapon is it's Systems Engineering culture. The SpaceX mafia is real (Vardra, Impulse, Relativity, STOKE, Radiant, Apex) and they are taking a wildly different approach. Here's 5 lessons you can take from SpaceX: 1. Every Engineer is a Systems Engineer SpaceX doesn't have traditional systems engineers. At SpaceX, engineers are called RE's, or responsible engineers. REs are domain engineers who take a systems eng mindset - taking ownership of both design and requirements to ensure integration across teams. The core realisation here is that either everyone is a systems engineer, or no one is. 2. Fundamentally Different Collaboration Model The core principle of the iterative approach is that It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This requires a great systems team to be networked not siloed. You need REs negotiating requirements directly, fostering a deeper understanding of the entire system among all engineers, and accelerates changes and improvements. This will lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration. Teams must adapt to late-stage changes, with rework likely. Constant change is the norm… 3. Every Problem is a Systems Problem Which system/team does reusability fit in? What about self-driving/cruise control? In order to solve really hard problems, every engineer needs to put the mission first and optimise their own system second. They must be willing to make sacrifices in their area (make a worse system, or delete it) for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice. 4. Systems Engineers Are Called “Design Reliability Engineers” In a world of RE's, what becomes of the systems engineer? They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss. Systems engineers graduate from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams. 5. Rename Internal Requirements to "Design Criteria" SpaceX distinguishes external requirements from internal design criteria. Why? It's about the mindset. The terminology encourages engineers to challenge and refine internal constraints. This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity. Disclaimer: All information is public and non-confidential. This post is not affiliated with or endorsed by SpaceX.

SpaceX's secret weapon is it's Systems Engineering culture. The SpaceX mafia is real (Vardra, Impulse, Relativity, STOKE, Radiant, Apex) and they are taking a wildly different approach. Here's 5 lessons you can take from SpaceX: 1. Every Engineer is a Systems Engineer SpaceX doesn't have traditional systems engineers. At SpaceX, engineers are called RE's, or responsible engineers. REs are domain engineers who take a systems eng mindset - taking ownership of both design and requirements to ensure integration across teams. The core realisation here is that either everyone is a systems engineer, or no one is. 2. Fundamentally Different Collaboration Model The core principle of the iterative approach is that It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This requires a great systems team to be networked not siloed. You need REs negotiating requirements directly, fostering a deeper understanding of the entire system among all engineers, and accelerates changes and improvements. This will lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration. Teams must adapt to late-stage changes, with rework likely. Constant change is the norm… 3. Every Problem is a Systems Problem Which system/team does reusability fit in? What about self-driving/cruise control? In order to solve really hard problems, every engineer needs to put the mission first and optimise their own system second. They must be willing to make sacrifices in their area (make a worse system, or delete it) for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice. 4. Systems Engineers Are Called “Design Reliability Engineers” In a world of RE's, what becomes of the systems engineer? They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss. Systems engineers graduate from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams. 5. Rename Internal Requirements to "Design Criteria" SpaceX distinguishes external requirements from internal design criteria. Why? It's about the mindset. The terminology encourages engineers to challenge and refine internal constraints. This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity. Disclaimer: All information is public and non-confidential. This post is not affiliated with or endorsed by SpaceX.

Is a Prompt Engineer a 'Real' Engineer?👷 The lines between traditional engineering and new-age skills like prompt engineering are becoming blurrier every day. Some might argue that if you're not building bridges or coding complex systems, you’re not a 'real' engineer. I’d challenge that notion. Prompt engineers are crafting the very instructions that guide AI in solving problems often bridging the gap between business and technology. So, are promt engineers 'real' engineers? Absolutely. The tools and methods may have changed, but the essence remains: solving problems by building robust technology solutions. So, Is a Prompt Engineer a 'Real' Engineer? What do you think?