I had a lightbulb moment when someone said 'the point of iterative approaches is not to find bugs, it's to do something (small) successfully and build confidence+learn'. There's a subtle but important difference between the iterative approach that SpaceX takes and 'debugging through exhaustive retries', and I'm worried NASA would look like the latter (and admittedly, some of the more recent starship launches look that way too).
The ability to pick a small-but-well-defined goal as an interim milestone - and stay focused on it - is a key skill, and too often I've seen waterfall-like companies slowly scope-creep their first MVP until it's a lumbering mess. You almost always need someone with a strong personality to push team to 'get it done', and that level of ownership is really hard to come by in an organization historically built around ass-covering.
I think Commercial Crew is the right model for NASA. Pick the design objectives, provide some level of scaffolding regulation (i.e loss-of-crew calculations), and then contract out to private sector to actually 'get it done'. (Yes Starliner was a failure, but Dragon is definitely a success. A 50% hit rate and success of the program overall is better than Artemis)
Not clear to me from the article - what's the different between an 'open rotor' engine and a turboprop (https://en.wikipedia.org/wiki/Turboprop)? At face value, both seem to be jet engines with propellers used on single-aisle planes?
The key insight here is the same reason why every internal department service eventually goes to a ticket system - adding queues (and by extension delays) improves efficiency. Resources can be used at 100% capacity ('always more work to do'), you can offer good service to only those who matter (i.e exec VIPs), and you can batch work (pour 2+ cups of brewed coffee at once).
Unfortunately it means that any time you need anything from someone outside your team, it comes with a lead time of '3-5 business days' unless you know the magic words or you raise it up the chain.
One of the big design challenges with self-driving cars like Waymo is communication with pedestrians - have to have some analogue to making eye contact or waving so pedestrians know they've been seen (possibly through audio or LED message signs)[0]
It's fascinating to me that a plane in full (emergency) autonomous mode, having run an algorithm to identify airport and landing sequence, is using speech to text to broadcast over analogue radio to the humans in the area. And the tower tentatively communicating back ('Outfitter 9, if you can hear me, cleared to land...') to do the expected final step in the exchange.
Have you tried going through Sales? Account teams can usually move mountains if they can see a clear path to a paycheque - you might have luck just by going to the 'chat with me' popup on the azure home page and saying you have thousands of budget and would like to chat with a rep.
In my experience, having a fixit week on the calendar encourages teams to just defer what otherwise could be done relatively easily at first report. ("ah we'll get to it in fixit week"). Sometimes it's a PM justifying putting their feature ahead of product quality, other times it's because a dev thinks they're lining up work for an anticipated new hire's onboarding. It's even hinted at in the article ('All year round, we encourage everyone to tag bugs as “good fixit candidates” as they encounter them.')
My preferred approach is to explicitly plan in 'keep the lights on' capacity into the quarter/sprint/etc in much the same way that oncall/incident handling is budgeted for. With the right guidelines, it gives the air cover for an engineer to justify spending the time to fix it right away and builds a culture of constantly making small tweaks.
That said, I totally resonate with the culture aspect - I think I'd just expand the scope of the week-long event to include enhancements and POCs like a quasi hackathon
I've come to appreciate that using AI tools are a skill on it's own. Anything beyond auto code completion takes quite a bit of conscious effort to experiment with and then learn how to delegate to in a workflow. They often end up being valuable, but it did take some work to get out of my productivity 'local maximum' that maybe not everyone would naturally take on.
The ability to pick a small-but-well-defined goal as an interim milestone - and stay focused on it - is a key skill, and too often I've seen waterfall-like companies slowly scope-creep their first MVP until it's a lumbering mess. You almost always need someone with a strong personality to push team to 'get it done', and that level of ownership is really hard to come by in an organization historically built around ass-covering.
I think Commercial Crew is the right model for NASA. Pick the design objectives, provide some level of scaffolding regulation (i.e loss-of-crew calculations), and then contract out to private sector to actually 'get it done'. (Yes Starliner was a failure, but Dragon is definitely a success. A 50% hit rate and success of the program overall is better than Artemis)