I've said this before, but it's worth repeating. There is a fundamental
mismatch between the Silicon Valley work-to-burnout company culture
described here and the space transport industry.
Typical burnout from this pace/pressure of work is about two years. At
that point you need a year off, or at least doing something low-pressure.
This works for Sili Valley because their typical projects ship in 18
months, give or take. By your two-year worker burnout, your project has
shipped and if it was a hit, your stock options may be worth a lot. You
can possibly afford to take that year easy. Then work to burnout
somewhere else another two years, rinse and repeat, then retire young
and rich - or at least move into a lower-pressure field before it kills you.
Typical space-launch product cycle is more like, what, five to seven
years? Only the typical "NewSpace" entrepreneur came to the industry
from, you guessed it, Sili Valley. So they do what they know. And they
can get away with it despite the mismatch because, well, space is so
friggin' cool, so there are always more eager recruits. But. This Sili
Valley model will be constantly losing rocket people to burnout not that
long after they're experienced enough to start being really productive.
And the projects risk dragging out far longer than they needed to
because of all the turnover.
In Sili Valley, it makes fortunes. In this industry, it weakens
companies, slows projects, and can lead to highly visible dumbass
mistakes out of high-turnover rookie inexperience or just sheer
exhaustion. We've all seen it.
The solution is simple, conceptually: Slow the work pace just enough so
burnout takes longer than the product cycle. Sundays off, period. One
or two Saturdays every month too. Send people home after twelve hours,
max. And make people actually use at least a week of their vacation time.
SpaceX seems instead, at least from what I see here, to be trying to
speed up the product cycle to be faster than burnout. But, alas, beyond
a certain point that only accelerates the burnouts and stretches the
product cycle further.
Make haste - well, not slowly - but a bit less hastily - and you'll get
there sooner. (And you'll put less of your effort into training a large
and motivated talent pool for your would-be rivals, if you happen to be
the current industry leader.)
Henry
On 4/8/2020 5:25 PM, Edward Wranosky wrote:
A person I knew who moved from Space X to another company said the motto was:
"If you don't come in on Saturday, don't bother coming in on Sunday either - you won't have a job."
On Wed, Apr 8, 2020 at 5:15 PM Ben Brockert <wikkit@xxxxxxxxx <mailto:wikkit@xxxxxxxxx>> wrote:
I'm sure the ex-SpaceXers have closer connections to people on the
program, but that also limits what they can say about it. This is what
a friend of mine relayed to me last year:
"I have a friend who is working on that project. Says this is the
worst period of his life. Working 16-18 hours per day. When I saw him
two weekends ago he looked like a shell of himself. These brilliant
engineers they recruit are going to be shit engineers after they burn
out.
"He showed me an email that made me speechless from Elon. Just
complete disregard for the health and well being of employees.
Literally said to get the job done at all costs."
That was last year, they've had a hiring push since then, maybe things
are working smoother now. But at most companies working on the CEO's
pet project can be the worst place to be; triply so with this CEO.
There are still people making arguments that working another marginal
hour never has a negative return. The problem is that the gains of big
pushes are immediate and the losses are often longer term; increased
turnover, loss of institutional knowledge, making unforced errors.
It's less impressive to build something really quickly if you destroy
it with no return really quickly, even if management then argues "well
it's good we learned this now instead of later" for things they didn't
need to learn.
And just that the workers are human and to work them to breakdown or
divorce or alcoholism is, to use the technical term, "totally a dick
move". Unfortunately the people who get to make those decisions are
often selected for their ability to not care about that.
Unlikely to happen now, but a way for the (job) market to better act
on that would be requiring companies to disclose their numbers on
turnover, fatalities, long term disability and other payouts to
injured workers. Knowing how many people never worked again after
taking a job at a particular test site would help people to make
better decisions.
Ben
On Wed, Apr 8, 2020 at 11:54 AM Michael Clive <zeinin@xxxxxxxxx
<mailto:zeinin@xxxxxxxxx>> wrote:
>
> Anthony,
> Those policies tend to always be the spoken rule at most places,
but I have seen them used in different ways. I have found there
are environments where there is a very steep political/personal
cost to slowing things down for safety reasons. I have also found
there are places that have iron-clad no-consequences
implementations of that rule. XCOR comes to mind.
>
> I would suspect that the Starship development group has a huge
amount of social pressure to not slow down the works, under any
circumstances. I would bet that someone knew this was a risk, but
someone else in the organization talked them out of reporting it,
much like what happened with the cone weld last time.
>
> The cultural norm on Starship seems to be forward-at-any-cost,
even if forward is directly into a brick wall, and anyone who
stands in the way of progress could be seen as weak or
not-a-team-player.
>
> One of the biggest unsolved questions for me (my own personal
Millennium prize) is a management theory one: Obviously, SLS style
management is a complete failure in terms of productivity per unit
time and per dollar spent. SpaceX style management is vastly
effective at reaching the goals set by Elon, at significant cost
to company culture. The question is: What is the middle ground?
How does a manager build a high performing company that
accomplishes great things with a low amount of chaos and waste?
are those mutually exclusive?
>
> On Tue, Apr 7, 2020 at 5:52 PM Anthony Cesaroni
<anthony@xxxxxxxxxxx <mailto:anthony@xxxxxxxxxxx>> wrote:
>>
>> Anyone on my crew can stop anything if they are uncomfortable
with it and will get my support if they make a mistake. We learn
this way, while improving safety and quality.
>>
>>
>>
>> Anthony J. Cesaroni
>>
>> President/CEO
>>
>> Cesaroni Technology/Cesaroni Aerospace
>>
>> http://www.cesaronitech.com/
>>
>> (941) 360-3100 x101 Sarasota
>>
>> (905) 887-2370 x222 Toronto
>>
>>
>>
>> From: arocket-bounce@xxxxxxxxxxxxx
<mailto:arocket-bounce@xxxxxxxxxxxxx>
<arocket-bounce@xxxxxxxxxxxxx
<mailto:arocket-bounce@xxxxxxxxxxxxx>> On Behalf Of William Claybaugh
>> Sent: Tuesday, April 7, 2020 8:44 PM
>> To: arocket@xxxxxxxxxxxxx <mailto:arocket@xxxxxxxxxxxxx>
>> Subject: [AR] Re: SpaceX Crumple Test
>>
>>
>>
>> Anthony:
>>
>>
>>
>> Spoken like a manager....
>>
>>
>>
>> Bill
>>
>>
>>
>> On Tue, Apr 7, 2020 at 6:37 PM Anthony Cesaroni
<anthony@xxxxxxxxxxx <mailto:anthony@xxxxxxxxxxx>> wrote:
>>
>> Isn’t it better to review, interview the crew and identify why
the error occurred? That way, the team learns and if there was an
individual responsible for the error, that individual can
recognize and preempt the situation from occurring again. That,
educates and reinforces the engineering and test system. If it’s
neglect, then that needs to be identified and the team needs to
understand why that happened as well, in order to mitigate neglect
going forward. Firing staff just causes people to cover up and
avoid responsibility in my experience.
>>
>>
>>
>> Anthony J. Cesaroni
>>
>> President/CEO
>>
>> Cesaroni Technology/Cesaroni Aerospace
>>
>> http://www.cesaronitech.com/
>>
>> (941) 360-3100 x101 Sarasota
>>
>> (905) 887-2370 x222 Toronto
>>
>>
>>
>> From: arocket-bounce@xxxxxxxxxxxxx
<mailto:arocket-bounce@xxxxxxxxxxxxx>
<arocket-bounce@xxxxxxxxxxxxx
<mailto:arocket-bounce@xxxxxxxxxxxxx>> On Behalf Of ken mason
>> Sent: Tuesday, April 7, 2020 8:18 PM
>> To: arocket@xxxxxxxxxxxxx <mailto:arocket@xxxxxxxxxxxxx>
>> Subject: [AR] Re: SpaceX Crumple Test
>>
>>
>>
>> It's such a basic mistake that could get some one fired on the
spot. Should of been double checked with other engineers and/or a
test reediness review meeting..
>>
>> But as they said, it's not a fundamental design error. So
suspect it will get done right the 2nd time. I recommend a high
volume (Cv) remote sensing dome loading regulator like a Grove
Poweractor or Tescom.
>>
>>
>>
>> On Tue, Apr 7, 2020 at 5:09 PM Jonathan Goff <jongoff@xxxxxxxxx
<mailto:jongoff@xxxxxxxxx>> wrote:
>>
>> I wonder how much of it was due to overworking their team. And
I wonder if they'll actually learn any lessons from that.
>>
>>
>>
>> ~Jon
>>
>>
>>
>> On Tue, Apr 7, 2020 at 5:00 PM roxanna Mason
<rocketmaster.ken@xxxxxxxxx <mailto:rocketmaster.ken@xxxxxxxxx>>
wrote:
>>
>> A rookie mistake from the world leader in launch vehicle
design. It happens and I won't throw the first rock.
>>
>> Import thing is to learn from our mistakes.
>>
>>
>>
>> On Tue, Apr 7, 2020 at 2:33 PM Bob Herguth <bob@xxxxxxxxxxxxxx
<mailto:bob@xxxxxxxxxxxxxx>> wrote:
>>
>> From the twitter feed.
>>
>> https://twitter.com/elonmusk/status/1246677676733104130
>>
>>
>>
>>
>>
>> From: arocket-bounce@xxxxxxxxxxxxx
<mailto:arocket-bounce@xxxxxxxxxxxxx>
[mailto:arocket-bounce@xxxxxxxxxxxxx
<mailto:arocket-bounce@xxxxxxxxxxxxx>] On Behalf Of roxanna Mason
>> Sent: Tuesday, April 07, 2020 1:09 PM
>> To: arocket@xxxxxxxxxxxxx <mailto:arocket@xxxxxxxxxxxxx>
>> Subject: [AR] Re: SpaceX Crumple Test
>>
>>
>>
>> Giving Space X the benefit of the doubt/speculation, my money
is on some equipment or component failure even a ruptured line
albeit such low pressures.
>>
>> Once again, a company that has the accomplishments that it has
under their belts, hard for me to believe it's something even I
would of avoided, with ease.
>>
>> Maybe they'll tell us.
>>
>>
>>
>> On Tue, Apr 7, 2020 at 12:05 PM Henry Vanderbilt
<hvanderbilt@xxxxxxxxxxxxxx <mailto:hvanderbilt@xxxxxxxxxxxxxx>>
wrote:
>>
>> On 4/7/2020 11:45 AM, roxanna Mason wrote:
>> > Back to this whole thing about Space-X failing that SS tank
makes no
>> > sense, are they that incompetent? Even I would of know the
>> > thermodynamic difference between GN2 and GHe. Just like my
pulse jet
>> > on GH2 draining a K bottle under 5 sec,it sails thru pipes and
>> > regulators,i.e.The square root of the diff of the respective MW.
>> > So it's git to be something else, I mean heck, they're orbiting
>> > satellites and recovering boosters almost routinely! Maybe
they're
>> > farming out some of their testing workload to save time.
>> >
>>
>> It's all speculation at this point. Worth throwing even the
less likely
>> possibilities out there to see if they might fit what's known.
The GN2
>> vs GHe thing was one such. Though, again, the most likely
related fail
>> would not have been miscalculated plumbing feed capacity - as
you've
>> pointed out, that is pretty basic - but rather a higher than
expected
>> chill rate of GN2 across a thin stainless bulkhead. (Mind, that one
>> might have gotten them even on GHe, if for some reason they
assumed some
>> interval during which they wouldn't need to make up pressure.)
>>
>> Simplest explanation is still either a test configuration error
or a
>> test hardware failure causing under-pressurization of the tank that
>> crumpled. Either way, it's likely a simple fix-it-and-move-on
thing.
>> Those few of us who care may well see the point casually
mentioned in
>> another context six months from now. The rest of the world
will sail on
>> regardless.
>>
>> Henry
