I'm sure everyone has worked with engineers who might be 10x on their own but drag the team down being inflexible or insisting on solving the wrong problem.
I like the saying that "engineering is a team sport" and agree that the multiplier should be on the productivity of the entire team as mentioned in the article. The concept of whole being greater than the sum of its parts applies to both engineering systems and technical teams (which we'd probably say is a type of system on its own).
Not meaning to downplay the role of great engineers... I suppose the best scenario would be 10x engineers who can also help the rest of the team perform better.
This is fantastic to see - I've been thinking about the need for something like this for a while.
I think there are two markets for this and I feel like you are already addressing the homeowners. Have you reached out to utilities who are looking to shave peak loads with DER?
Wow - that was painful to read because I can relate so much. Thanks for sharing. Another aspect of such dysfunction is the diffusion of responsibility that comes with it. The stubborn people who pushed for a particular solution rarely suffer ill consequence because the decision was technically made as a group.
I think a functional engineering decision process is more akin to a veto process. Someone, say Olivia in your example, would be tasked with selecting the language for the job and submitting the technical rationale for it and the relevant authorities (e.g. CTO or product owner) would sign off on the decision. They will normally have the power to approve or reject but not to impose certain solution. In a traditional hardware engineering, this is how it's done, where an engineer submits a design and it needs to be approved by relevant subject matter experts in various domains, such as material, thermal, structure, safety etc.
I recommend this essay often to people, especially in a start up. When someone describes their organization as being "flat", it's often a red flag because it means that there are unwritten power structure that newer employees will likely be excluded from.
I understand there is updates being made to the space export control rules (https://www.space.commerce.gov/new-space-export-control-rule...) regarding space/satellite components that were previously classified as ITAR. I've been curious to know if this will enable Canadians to apply to some space/aerospace technology companies in the US that were restricted to US citizens only?
Woah - this is strange. This was posted yesterday but I see that the timestamp has changed so it's only 4 hours old now. The timestamps for the comments seem to have changed also.
Fair enough. I feel like I've been seeing a lot of questions on Reddit along this line that comes off as very low effort to generate engagements so that's really the reason behind my comment but I see how my response also comes off as snarky.
I never got to ask this as an interview question, but I always thought it would be interesting to ask - 'if you were wrong, would you want to know?' Not on any particular topic but in general. When I asked this in casual settings, I thought it was illuminating that no one gave a simple 'yes' as an answer.
Interesting to know - thanks for the info. Strange to think that something designed for 'known, understandable, repeatable work' got adopted by software development.
Not an issue if one can do both but when there's a conflict, a great engineering firm will prioritize safety & quality over profit, whereas a business will prioritize profit & stock price over safety & quality.
Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.
Yep - certainly lessons learned through painful experiences.
Supply chain management is incredibly challenging and it's interesting to see one school of thought moving away to vertical integration as an alternative solution and another doing just as well with suppliers (Airbus, Apple, ASML, etc).
The way the project was structured, it was in the interest of everyone to succeed since everyone paid for their own development cost and only made money when the planes were sold. Not the easiest client to work for mind you - I've been told that many companies flat out refuse to work with them, but again, thinking back, I think that's what made the project a success, although extremely stressful.
Can confirm. I worked as Airbus' tier 1 supplier and they were even accompanying us to manage our own supplier, which in hind-sight, ensured that things like this didn't happen.
This was the practice of 'configuration management' - I mentioned it in another thread but a lot of this is discussed in the book 'The Secret of Apollo'. It's a quite a good read and gave me a whole new appreciation for the practice of configuration management and document control, something that many engineers abhor.
Another book that I enjoyed on the topic - "The Secret of Apollo: Systems Management in American and European Space Programs". This also comes to the same conclusion that it was the systems engineering process that allowed it to succeed.
"Need 10+ years of experience in nuclear detonation device."