[whoisthemachine]

> The bigger problem is that NASA's culture is so meeting heavy that it's hard to justify these kinds of low importance events on my calendar.

Not sure if you are speaking from experience, but if that is the case, and this is true, then NASA as an organization seems to be a poor judge of what's important.

[0xffff2]

Yes, from experience. It's not that we don't know what's important, it's that it's all important and I have to find time to actually write code every now and then too. The real problem is just that we're all very busy and it's not really possible for everyone in the agency to have even a cursory awareness of everything that's going on.

Even now with everything being virtual, I get invites to brown-bag type events probably 3-4 time per week. I can go to one or two, but there's no way I can fit every single one into my schedule.

[whoisthemachine]

Interesting. Do you think there's a chance for more balance or does it seem just a natural result of the demands of the job?

[0xffff2]

There are a couple of issues at play. One is that there's so much interesting stuff going on that I (and most of my colleagues) tend to volunteer ourselves for lots of projects, which results in us going "deep" on a couple of projects at the expense of not having enough time to go "wide" by attending lots of talks that aren't directly related to our own work. That part's on me and I really could make more time in my schedule if I just said "no" more often (but again, I don't say "yes" because I'm pressured to do so, I say "yes" because the work is really fun and interesting!).

The other question is why we have so many meetings per project. That one's tougher to tackle and I don't really have an answer. The one thing that I have identified is that we're very in to making sure that everyone has their say on things before taking action. That's a good thing overall, but it also leads to tremendous meeting bloat. A meeting that would only take 5 minutes if everyone restricted themselves to discussing critical issues before making a decision regularly takes a full hour in which we examine every pitfall, no matter how minor.

[whoisthemachine]

Interesting, it sounds like in this case it's mostly a good problem to have - even ensuring all voices are heard is good, from a sound engineering perspective, which I'd imagine is important for NASA's missions!

I wonder if there would be a benefit in your case if folks had to follow a similar process to the one Amazon requires for its meetings (this may be something NASA already does, but I will admit I'm projecting a bit here and am wishing my organization required some writing before calling for a meeting):

> We don’t do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of “study hall.” Not surprisingly, the quality of these memos varies widely. Some have the clarity of angels singing. They are brilliant and thoughtful and set up the meeting for high-quality discussion. Sometimes they come in at the other end of the spectrum.

> ...

> Here’s what we’ve figured out. Often, when a memo isn’t great, it’s not the writer’s inability to recognize the high standard, but instead a wrong expectation on scope: they mistakenly believe a high-standards, six-page memo can be written in one or two days or even a few hours, when really it might take a week or more! They’re trying to perfect a handstand in just two weeks, and we’re not coaching them right. The great memos are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can’t be done in a day or two. The key point here is that you can improve results through the simple act of teaching scope – that a great memo probably should take a week or more.

https://www.sec.gov/Archives/edgar/data/1018724/000119312518...