The team shape

Most teams reading this have one person doing all three jobs, and there is nothing wrong with that. The three roles are three sets of standards, not three headcount requirements. The problem is not the overlap, it is the invisibility of the overlap.

When the same person lands the data, models it and analyses it, the internal handoffs disappear, and with them the moment where somebody checks. She adds a column to a mart for one dashboard, because as the analyst she needs it today. As the analytics engineer she would have asked whether that column belongs at this grain and whether anything else will now depend on it. Both instincts are hers, and the second one loses, because there was no point at which the hats were separated.

The fix is cheap: write down, on one page, which layer she owns in which capacity, and what standard applies to each. When she is working on a shared definition, that is analytics-engineering work and it gets reviewed even if the reviewer is only a colleague reading a diff. When she is exploring, it is analyst work and it does not. Naming the layer is what lets one person hold two standards.

The fastest way to tell whether a data team's structure is working is to ask what moves between the roles. If the answer is meetings, the structure is not working, however good the meetings are, because a meeting leaves nothing behind that the next person can read.

• Data engineer to analytics engineer: a declared source with an agreed freshness expectation. Written down where the transformation layer can see it, so the whole estate has exactly one place where a raw table name appears.
• Analytics engineer to analyst: a mart with described columns and a test suite. The description is the handoff. If an analyst has to ask what a column means, the handoff did not happen, it was just scheduled.
• Analyst back to analytics engineer: a written request naming the field that does not exist, or a piece of logic they have now written twice. The second one is the important one and it is almost never captured.
• Everyone to everyone: the review. A proposed change that somebody else reads before it ships, which is the next part of this session.

Notice that all four are things, not conversations. You can still have the conversations. But a structure held together only by conversation degrades the moment somebody is on leave, and it cannot be onboarded into.

The analytics engineer is the hard hire, because the combination is unusual. You need genuine SQL depth, which is common, plus software habits, which is common, in the same person, which is not.

• SQL depth means window functions, grain, and knowing why a join fanned out without having to run it twice. It is testable in half an hour and you probably already know how.
• Software habits means version control as a daily reflex, review as a normal part of shipping rather than an insult, and the assumption that anything important has a test. This is the half that interviews usually skip.

The signal worth watching for: the candidate brings up tests before you do. Ask them to describe a data problem they fixed, and listen for whether the story ends at "and then I fixed the query" or at "and then I added a check so it could not silently happen again." The second answer is rare, and it is the whole role. Somebody who volunteers tests unprompted has internalised the thing that separates this job from writing analysis SQL well.

The mirror-image hire is worth naming too. An excellent software engineer with no feel for grain will build you a beautifully maintained estate of models at the wrong grain, and the tooling will help them do it faster. Both halves, or you are trading one failure for another.

Review works when the reviewer has standing to object, which means the pairing is not arbitrary.

• A shared-core model - a conformed dimension, the definition of revenue, anything more than one domain depends on - is reviewed by the central owner of that core. Always. This is the review you never delegate, because it is the one that keeps five definitions from becoming five numbers.
• A domain's own mart is reviewed inside the domain, by another person in that domain who understands the business meaning. Central does not need to approve it, and insisting on approving it is how you become the ticket queue.
• Anything touching a source declaration is reviewed by the data engineer who owns the landing, because they are the only person who knows what upstream is about to do.
• An analyst's exploration is not reviewed at all. That is deliberate. Review is a cost, and spending it on work that nothing depends on is the fastest way to make people resent the whole practice.

That last point is worth saying to your team out loud. Review everything and you have built a bottleneck with good intentions. The shape you want is: heavy review on the shared core, light review inside domains, no review on exploration. The layering is what makes that distinction possible, which is one more reason the conventions matter.

Leaders do not need to run these reviews, but you should know what a good one looks like, because "we review everything" is easy to say and hard to verify.

• Is the grain what the model claims? One row per what. This is the question that catches the most expensive class of mistake, and it comes from the modeling discipline rather than from the tool.
• Does this change a shared definition? If yes, who else is affected, and have they been told. The dependency graph answers the first half mechanically.
• Is the new thing tested? Session a3's argument, applied one change at a time. A reviewer asking "what test defends this" is how a test suite grows without anyone running a testing initiative.
• Is it in the right layer? Joins in staging, business logic in three places, a mart joining two facts: all of these are cheap to prevent in review and expensive to unwind later.
• Could the next person read it? Not style policing. Genuinely: does the description say what the column means, so nobody has to reconstruct intent from the SQL.

Five questions, no tooling required, and they are the same five whichever option session a4 landed on.

Both shapes have a tell, and both tells are visible without any instrumentation.

The ticket-queue tell is a shadow estate. Somewhere in your company there is a folder of spreadsheets, or a dashboard nobody in the data team has seen, that does the job the queue was too slow to do. People are not being difficult; they had a deadline. Ask how long the longest-waiting model request has been open this quarter, and then ask what the requester did in the meantime. The answer to the second question is the size of your shadow estate.

The five-revenues tell is a reconciliation meeting. Not one meeting: a standing one, where two teams bring different numbers for the same thing and spend an hour establishing which is which. That meeting is a symptom being managed rather than a problem being fixed, and its existence usually predates anybody noticing it is unusual.

The middle path is not a compromise between these, it is a different structure. Central owns a deliberately short list of things everybody depends on, and owns the conventions and the review bar. Domains own everything else and build on top. What central sells the domains is not permission, it is leverage: a dimension that is already conformed, a definition already agreed, and a review that catches the mistake before their stakeholder does.

Decentralised ownership is popular in slide decks and rare in practice, because it has a precondition most organisations skip: the domain has to be capable of owning the thing, and capability means people, standards and consequences.

• Somebody in the domain has the skills. Not "an analyst who is good with SQL" but someone who will meet the review bar and write the tests. If nobody in the domain can do that, you have not federated ownership, you have federated the blame.
• The standard is central even when the work is not. Conventions, the review bar, the test expectations, and how documentation gets produced. Distributed teams with no shared standard produce five estates, not one.
• The domain owns the consequence. When their mart is wrong, their stakeholder calls them. If it routes back to the central team anyway, ownership never moved and everybody now has two owners for one thing.

The honest version for most mid-sized organisations is: federate later than the deck suggests. Start central, keep the shared core small and well defended, and hand a domain its own marts the moment that domain has a person who will meet the bar. Not before.

The prompt. "I am going to write five layers on the board: sources, staging, our shared definitions, the marts, and the last mile. For each one I want one name as owner and one name as reviewer. Not a team name. A person. If you cannot give me one name, say so and we will write 'unclear', which is a real answer."

What a good answer sounds like. Some rows fill in instantly, one or two produce a pause, and at least one gets 'unclear' written next to it. The word 'unclear' appearing on the board is the success condition, not a failure: it means an assumption that was previously invisible is now a line item somebody can be assigned. Ideal output is five owners, three or four reviewers, and one or two honest gaps.

The failure mode to listen for. A team name in the owner column. "The data team owns staging." That is exactly the implied ownership this exercise exists to surface, and it feels like an answer while committing nobody. Push once, politely, for a person. If the room genuinely cannot name one, that layer has no owner, and the sentence to say out loud is: "then when it breaks, everybody will assume somebody else is handling it."

The prompt. "Everyone take thirty seconds and write down, privately, how our headline number is defined. Include what is excluded. Then we read them out." Use whatever your equivalent of settled revenue is: the number that appears on the board pack.

What a good answer sounds like. Genuine convergence with one or two edge cases surfacing: three people write the same thing, and a fourth adds "net of refunds, but I think we include failed payments that later settle." That edge case is the actual finding, and it is now a decision somebody can own rather than a difference that shows up quarterly in a reconciliation.

The failure mode to listen for. Two structurally different definitions, both confident, from two people who work together weekly. That is failure shape 2 in miniature, and the important part is what happens next: if the room's instinct is to decide which is right, good. If the instinct is "well, we use different ones for different purposes", you have a naming problem being described as a nuance, and both numbers will keep appearing on slides with the same label.

The prompt. "Take the last three changes to the model behind our most-used number. For each one, tell me who proposed it, who read it before it shipped, and how long the reading took."

What a good answer sounds like. Three names in the reviewer column, with at least one review that produced a change. A review that never asks for anything is attendance, not review, so the healthy signal is a story like "Priya asked what happens to cancelled orders and we added a test."

The failure mode to listen for. "Same person proposed and shipped all three, and it was fine." It probably was fine. The point is that you have no mechanism, only a track record, and a track record does not survive that person being busy. This is also the exact answer that tells you the tooling from session a4 is not paying for itself yet, because every benefit it offers is downstream of somebody else reading the change.