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.

After that, it helps to think through what project lifecycles and workflows are shared across DS. It should be easy for stakeholders to understand what it means to work with DS, as well easy for DS outside of your team know where they're at if they join an in-flight project.

These are high level thoughts, but in general, DS has a lot to learn from the DevOps world. Some companies try to solve the "shift left" issue by embedding their DS in a matrix organization and that CAN work, but I'm not convinced it's the scaleable answer.

Just look at infosec. There's not a security engineer embedded on every single feature team. Modern software is not perfectly secure, but it's still a hell of a lot more secure than it's been in the past.

So too with data science. We want to make it easy for decision makers to do the right thing when it comes to data usage. We don't need every decision to be perfectly data-driven, but we do want decisions to be a hell of a lot more data-driven than they have been in the past.

And we won't get there with by trying to brute force our way in. We gotta shift left.