Building the team to grow Snowflake across functions and business units

A diversified manufacturer was pulling data from several business units, ERP systems and old warehouses into Snowflake. The first version handled reporting. The company wanted to go further, into supply chain analytics, pricing, inventory, secure data sharing and AI.

In manufacturing, Snowflake work can stretch across ERP consolidation, pricing, distributor optimization, inventory and plant capacity. That makes the talent need a lot wider than warehouse administration.

The company had Snowflake developers but no one person owning platform strategy, data product standards, cost control or adoption across the business. Hiring more developers would add capacity without fixing any of that.

What they needed was leaders to set the model, architects who could design for many business units, and builders who understood ingestion, modeling, security, performance and DataOps.

We mapped the Snowflake roadmap to a hub and spoke team. A central platform group would own the account architecture, standards, security, performance and enablement. Domain teams would own finance, supply chain, commercial and manufacturing data products.

We calibrated each search. Direct Snowflake depth was required for the platform architect, administrator and senior engineers. Comparable warehouse, SQL, dbt and cloud experience could transfer into some analytics engineering and data product roles.

Leadership:

• VP of Data or Data Platform Director
• Owns the data strategy, operating model, business alignment and value delivered

Architects:

• Snowflake Platform Architect
• Enterprise Data Architect
• Data Security Architect

Builders:

• Snowflake Data Engineers
• dbt and Analytics Engineers
• ELT and CDC Engineers
• DevOps and DataOps Engineers
• Platform Administrator
• Performance and Cost Optimization Engineer

Domain and adoption:

• Finance, supply chain and manufacturing data product owners
• Data Governance Lead
• Data Stewards
• BI and Semantic Model Engineers

We assessed people on:

• Snowflake account, warehouse, database and schema design
• Advanced SQL, dbt, ELT, CDC and data modeling
• RBAC, masking, row level security, secure sharing and governance
• Query tuning, workload isolation and cost control
• CI/CD, infrastructure as code, testing and observability
• ERP and multi business unit integration
• A track record of enabling self service without losing control

We looked at technology fit and operating model fit together. We wanted people who could balance central governance with domain ownership, not people focused only on warehouse development.

We also separated "I was on the project" from "I owned it." Candidates had to walk us through their design decisions, the trade offs, the problems they hit and the adoption they got.

We leaned on advisors who run Snowflake at scale. They vetted the leaders on operating model and cost ownership, and the builders on account architecture, security, performance tuning and dbt. Many candidates came from our Snowflake and analytics engineering community, so we could check reputation and real work before anyone sat down for an interview.

Clarity on which Snowflake work belonged in the center and which belonged inside the business. That kept them from building yet another reporting bottleneck.

The team could grow Snowflake across business units, keep consumption costs under control and build data products others could reuse. Having this talent in house also gave the company more leverage with vendors and consulting partners.