Katie Bauer!

"First, it's much easier to make sure that the people build the software are doing the right thing than inspect nearly completed systems and features to find a significant architectural problems and defects that involve substantial rework."

"Second, information security teams simply don't have the capacity to be doing security reviews when deployments are frequent."

If you've ever lamented that you as a DS are brought into the loop too late, these ideas are worth paying attention to. The artifacts you produce are different from those of an infosec engineer, but the concepts are exactly the same.

"Easy-to-consume" depends on what your team's responsibilities are, but they're all about format. Maybe it's bullet points in the executive summary of your write up, maybe it's a good SELECT * style aggregate table, maybe it's well thought out data models underpinning your tools

The theme here is friction reduction. If someone wants to use the knowledge generated by your DS team, they shouldn't have to be a specialist to obtain it

"Preapproved libraries, packages, toolchains" seems most related to the quality of your data platform. How fragmented is your data warehouse or your tool ecosystem? Does one person use sklearn while another uses statsmodels while another person uses Tensorflow?

Translating between different tools and libraries can be a real nightmare. Worse case scenario, you get different answers from each. Best case, you have to spend extra time converting between them just to build on work done in another part of your organization.

"Processes" might seem easy to generalize, but it's harder than you think. IMO the most important dimension of this is being aligned with the rest of your data org (and adjacent orgs) on what DS can and can't do.