The setting
's extracts data from source systems and loads it into a customer's data warehouse, ready to query. Fivetran engineers write the connectors that link each source.
A repeatable acquisition programme meets reporting requirements that differ by subsidiary.
Shared architecture protects consistency, while local acceptance protects the reporting each acquired business still needs.
Who you’d be doing this for
“We connected the new subsidiary last month, and their controller still asks me for the old report every Friday.”
Alvaro Campos · Enterprise Data Architect · a character in this brief
Coordinates integration of acquired subsidiaries into the parent company's analytical environment.
What is at stake
Only two of nine subsidiary workloads reached accepted production use within 60 days. You must weigh a repeatable customer programme against the local architecture and reporting decisions that need individual attention.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- repeatable enablement vs subsidiary-specific reporting
- shared learning vs acquisition confidentiality
- workload adoption vs specialist capacity
- central architecture consistency vs local business acceptance
Why Fivetran
Expansion across subsidiaries depends on customers turning existing connectors, Snowflake, and dbt into reporting their acquired businesses actually use.
Written with these in mind
Not your kind of problem? 54 more at Fivetran, or browse every organization.
Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.
The organization context comes from public information. The situation and characters are written for the brief.
Job postings it was written from
Public descriptions of the work at Fivetran. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.
- Sr. Customer Solutions Architect (opens in a new tab)
- Own Mutual Success Plans and shape Mutual Account Plans with the AE, mapping whitespace across business units, subsidiaries, and use cases
- Shape the account plan and own the technical side of the expansion pipeline, translating executive-level customer initiatives into scalable data workloads and solutions
- Customer Solutions Architect (Denver) (opens in a new tab)
- Customer Solutions Architect (NYC) (opens in a new tab)
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.
Where similar work appears
Other live briefs connected to this one, and what connects them.
Similar problems at other organizations
Like this one, each of these is about people starting something and never quite finishing it.
New creator groups are waiting for access because administrators cannot point to a safe first production path.
You have to weigh faster seat adoption against the review habits that protect branded output.
Six Pages customers still depend on developers to move customer files.
You need to weigh guided production adoption against a service commitment small application teams cannot sustain.
Only 18% of enterprise trials configure access and create a shared table after arriving from paid acquisition.
You have to weigh broad AI appeal against a message that qualifies administrators for the workflow that drives adoption.
The same setting, from another role
Each is set around Fivetran’s Fivetran data pipeline platform (managed ELT), written for a different role. They’re separate briefs, not the same scenario.
Completed connector runs are leaving some warehouse tables behind when morning reporting begins.
You decide where the system's reading of a failed run stops and the on-call engineer's own check across traces, run history, and pull requests begins.
Large reloads can consume the same warehouse window that scheduled reporting depends on.
You have to weigh a useful estimate against the risk of overstating what past runs can predict.
Duplicate completed runs are loading the same batch twice into customer warehouses.
You must weigh retry recovery against a permanent definition of a completed run.