An internal onboarding and deployment guide for the ConnectWise Data Services team. This is the operational playbook for how analysts join the data platform, develop transformations, and deploy changes to production. The document demonstrates what it looks like to build a real analytics engineering process inside a mid-size SaaS company.
Core Philosophy
"You are an arbiter of truth and your contributions will help build ConnectWise's brain."
The opening frames analytics work as foundational to organizational intelligence. Without reproducibility and consistency, data silos emerge, conflicting metrics erode trust, and gut decisions replace informed ones. This connects to [[06-reference/concepts/analytics-as-craft]] -- analytics as a discipline with standards, not just ad hoc query writing.
The Data Platform
The onboarding covers the full modern data stack:
| Layer | Tool | Purpose |
|---|---|---|
| Loading | Fivetran | Source system sync |
| Storage | Snowflake | Central data warehouse |
| Transformation | dbt | SQL-based modeling |
| Scheduling | dbt Cloud | Job orchestration |
| SQL Authoring | DataGrip | Query development |
| Development | VS Code | dbt project work |
| Version Control | Git + GitHub | Code management |
| Visualization | Power BI | Dashboards |
| End-user | Excel + ODBC | Ad hoc analysis |
Access and Tooling Checklist
A detailed operational rundown of how to get access to each system -- who to email, what licenses to request, what CC lines to include. This level of operational documentation is a hallmark of [[06-reference/concepts/systems-over-goals]] thinking: a repeatable process rather than tribal knowledge.
Pull Request Workflow
The deployment process centers on a Git-based PR workflow:
- Commit final changes on your working branch
- Switch to
release, pull latest - Merge
releaseback into your working branch, resolve conflicts locally - Push working branch to remote
- Create PR on GitHub
- PR triggers review from analytics peer + Data Governance for business logic impact
- PR must pass checks before merging to master (production)
The key cultural insight: "The review may be critical of some decisions, but none of it should be taken personally. You are about to make a permanent contribution to how the business is understood and operates."
Sections Outlined but Incomplete
The document has the scaffolding for several important sections that were still in development:
- dbt Overview
- SQL Style Guide and CTE conventions
- Documentation standards (Sources, Models, Exposures, Tests)
- Reporting Development and Deployment
This incompleteness itself is telling -- it shows the real state of a growing analytics team trying to formalize processes while simultaneously delivering. Relevant to the [[06-reference/2026-04-03-the-e-myth-revisited]] tension of working IN the business vs. ON it.
Reusable Patterns
- PR as governance checkpoint -- Using the pull request as a natural point for both technical and business review
- Onboarding as documentation -- Writing the onboarding guide forces you to document the platform
- Access request templates -- Standardized email patterns for system access reduce friction
- "Release branch" pattern -- A staging layer between development and production for side-by-side impact analysis
Consulting Credibility
This document shows the ability to design and document analytics team processes from scratch -- a key skill for [[01-projects/phdata/index]] consulting work. The PR workflow, access patterns, and onboarding structure are directly deployable templates for any data team engagement.