Data Maturity: When to Switch Processes and Tool Stacks

Summary

A panel discussion on how data teams should evolve their processes and tooling as their organization matures. Three key takeaways:

1. Decisions, not tools. It is easy to lose sight of the purpose of analytics work. The goal is better decisions, not fancier dashboards or more sophisticated pipelines. Tool selection should follow from decision-making needs, not the other way around.
2. Security basics matter at every stage. IP restrictions and two-factor authentication are table stakes -- not something to defer until "later."
3. Hire consultants for one-time work. Organizations at any maturity level should recognize when a problem is a one-time project (migration, implementation, audit) vs. an ongoing capability. Consultants are the right fit for the former; full-time hires for the latter.

The consulting insight is directly relevant to how [[01-projects/phdata/index]] positions its value: clients hire phData not because they lack smart people, but because certain work (Snowflake migrations, Cortex AI pilots, data architecture reviews) is project-shaped, not role-shaped. This same logic appears in [[06-reference/2026-04-03-selling-data-science]] -- half the job is framing the work so stakeholders understand what they are buying.

The "decisions not tools" framing connects to [[06-reference/concepts/compounding-knowledge]]: maturity is not about accumulating tools but about building judgment for when to change them.

Open Questions

• What signals indicate a data team has outgrown its current stack vs. just needs better processes on the existing one?
• How does this framework apply to solo/small-team operations like [[01-projects/data-marketplace/index]] where the "team" is one person plus agents?
• Is there a maturity model for AI agent tooling analogous to what exists for data team tooling?