Galxeagle

> Wanted to work with tech from a more overarching level

> I get a huge sense of accomplishment seeing customers user our product’

> Interface between business and tech

You might like trying your hand in Professional Services either at a System Integrator like Deloitte or first-party in a product company (now often re-labelled as ‘forward deployed engineers’).

Their main problem space is getting customers to successfully use the product through marrying your understanding of the tech’s limitations and sweet spots with the customer’s organizational goals and culture, so daily work revolves less around deep technical design and more about org alignment and strategy (which is why SIs sometimes get a bad rap on a tech forum like HNews).

It probably pays less, and it can be more stressful when you’re billing for (and justifying) every hour, but in my experience the way it tends to be more dynamic (new projects+teams+customers often) and how you get to see very direct impact is quite rewarding.

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)

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.

well I never said their sales team was good ha

Thanks for closing the loop - always interesting to hear about any progress when stuck in a bureaucratic logjam.

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.

Any extra time spent during a burn is wasted fuel. Intuitively, any time before the rocket is in orbit, some part of the rocket thrust is resisting the force of gravity or else it would fall back down to earth. The longer that time is, the more thrust (and thus fuel) was spent negating that force. It's the main reason why the Falcon 9 boosters do a 'hoverslam' on return and land at close to full throttle - any extra time during that burn is less fuel efficient.

Better fuel efficiency = more payload to orbit = plenty of justification for the extra complexity.

Admittedly gravity losses are more significant at the beginning when the booster/ship are ascending purely vertically than later in second stage flight which is mostly horizontal, but definitely still a factor.

Also from a license negotiation perspective, gives the buying company the option to threaten to self-host and/or fork. Even if they never do (and I'm sure the source company is very careful to balance the value story), it can act as a ceiling for rate increases or other annoying business practices.

Why would a company ever open-source their product then? Giving up that complete leverage can be a selling point during the purchasing process, making buyers more comfortable that they won't be (completely) locked in, and be a net positive on revenue through faster sales.