rw-book-cover

Metadata

Highlights

Data teams have learned a lot from software teams, and will certainly learn much more, but one area we cannot emulate our software engineering peers is organizational topology (View Highlight)

instead of making arbitrary divisions based on standard business areas, focusing on greater alignment between the organization’s knowledge graph and people graph. Far from shipping the org chart, this is an alignment that moves in both directions, organizing people around the ways data flows as much as organizing data projects around groups of people. (View Highlight)

A common pattern to handle this setup today would be ‘hub and spoke’, using a central team to land and stage the data, then have the embeds build on top of this in separate areas of a shared project or in separate projects that import the central project (and potentially others (View Highlight)

(View Highlight)

Wouldn’t it make more sense for the product analyst to own the entire transformation vertical for that data source? Why arbitrarily force them to go to a separate team to, say, unnest a JSON field differently, and all the ensuing downtime that handoff would take? On the other hand, our finance and marketing analysts are actually working from a shared set of components, but they are better served to separate past a certain level to simplify their projects and allow independent development (View Highlight)

Something like the below would make a lot more sense for our organization: (View Highlight)

(View Highlight)