Role Responsibilities and Success Criteria Questions

On a data platform, the security architect owns the policy and design layer, deciding what "secure" means for the platform and turning that into frameworks, threat models, and control mappings, while the data engineer builds the pipeline inside those guardrails. The escalation rule that falls out of that split: bring the security architect in whenever a change introduces a new category of risk, not after you have already built something and want it reviewed.

Typical deliverables

A security architect on a data platform usually produces: a data classification scheme (for example public, internal, confidential, restricted) mapped to a control framework such as SOC 2 (a widely used third-party audit standard covering how a company handles and protects customer data) or NIST 800-53 (a US government catalog of security controls), so "confidential data" implies the same encryption and access rules no matter which pipeline touches it; a threat model, meaning a diagram of how data moves through the platform (ingestion, storage, transformation, export) with each hop annotated with what could go wrong there and who could exploit it; and a control mapping that ties each identified risk to a specific technical control, for example "risk: PII (personally identifiable information) exposed in an analytics export" maps to "control: column-level masking plus export audit logging."

How architecture informs pipeline design and governance

The security architect sets the guardrails, the data engineer implements inside them. That means: encryption standards for data at rest and in transit (which key-management service handles keys, minimum TLS, meaning transport layer security, version), least-privilege IAM (identity and access management) boundaries for every pipeline service account, and retention and classification policy that determines how long a table lives and whether it needs an automated deletion job for data-subject deletion requests. The data engineer then writes the actual pipeline steps, the encryption call, the IAM role definition, the retention job, the masking transform, rather than inventing the policy from scratch.

When to escalate, concrete examples

Escalate to the security architect when: a new external source starts sending a field that looks like personal data but has never been formally classified, before you build the ingestion path for it; a request asks you to replicate customer data into another region or country, because of data-residency and threat-model implications even if the pipeline change itself is small; an access request would grant a service account broader permissions than its documented least-privilege boundary, rather than quietly approving it yourself; or you discover an existing export or extract-transform-load flow running in production that does not appear in any current threat model, a "shadow" pipeline that needs to be modeled and controlled, not just patched.

Worked example

Imagine you are onboarding a new vendor's webhook feed and notice it includes a "customer_email" field never seen from that source before. You pause before wiring it into the warehouse, flag it to the security architect, and together you classify it as confidential, add a line to the threat model for this new ingestion hop, and map it to the existing masking control used for other email fields. Building the pipeline before that conversation would have shipped an unclassified PII field with whatever default access the warehouse happened to have.

Trade-offs and pitfalls

A data engineer who escalates every question, including routine ones an existing control mapping already covers, becomes a bottleneck and erodes the working relationship with the security architect. A data engineer who never escalates and just encrypts everything "to be safe" wastes engineering time and can still miss the real risk, for instance encrypting a field that was already de-identified while leaving an actual PII column in plain text because nobody flagged it. The right calibration is to escalate on new risk categories or genuine ambiguity, and handle a routine, already-covered case (which encryption library to call for a field already classified as confidential) yourself against the existing standard.

Direct answer

Ask to see the artifacts a team actually uses to run itself, not just a description of its service-level agreements (SLAs, formal commitments about uptime, latency, or accuracy) and service-level objectives (SLOs, the internal targets a team holds itself to, which may be stricter than the external SLA). A team with real operational maturity can produce a dashboard and a runbook on request; a team that's only aspirationally following its targets will describe numbers it can't actually show you.

Dashboards to request

"Could you show me, or describe, the dashboard you look at to decide if the service is healthy right now?" A specific answer naming actual metrics, like 99th-percentile (p99, the value below which 99% of measurements fall) latency or error rate, is a good sign; a vague "we just check if things are broken" is a warning sign.

Runbooks to request

"What does the runbook for your most common alert look like?" Ask to see an actual on-call runbook, or at least hear a specific example of a step-by-step response to a real past incident.

On-call interviews

Ask to speak with, or ask about, whoever is currently on-call: "What's the last page you got, and what did resolving it involve?" "How often does the team get paged outside business hours, and how has that trended?"

Signals the targets are realistic, monitored, and owned

Realistic: the target is specific and has a rationale that traces to something outside the team, like "our client SLA is 300 milliseconds, so we hold an internal SLO of 250 to leave ourselves room to react before we breach the contract," not a round number nobody can justify. Listen specifically for that gap between the two numbers. A team whose internal objective is set exactly at its external commitment learns it has a problem at the same moment its customer does, which defeats the reason the objective and the agreement are two separate numbers in the first place, so hearing an SLO quoted as identical to the SLA is a sign the distinction is nominal. Monitored: the team can show you a live number against the target right now, not just describe it from memory. Owned: there's a named person or rotation responsible when the target is breached, and the team can describe what happens next, who gets paged and what the escalation path is, rather than "someone probably notices eventually."

Worked example

If I ask what the current p99 latency target is and where the team stands against it, and the interviewer immediately pulls up a number and says "target's 250 milliseconds, we've averaged 230 this month, breached it twice after a deploy last week and rolled both back," that's strong evidence of a real, owned SLO. If instead they say "I think we have a target somewhere, let me check with someone," the target exists on paper but isn't operationally alive.

Trade-offs and pitfalls

Pushing too hard on this in an early screening interview can feel adversarial, so calibrate depth to the interview stage and to whether you're talking to the hiring manager or a future teammate. The bigger pitfall is taking a confident verbal answer at face value without asking for the artifact behind it, confidence isn't the same as evidence.

Before I join a new team, I want answers in four areas: what I'll be measured on, what data and tooling I'll inherit, how the team actually operates day to day, and what's already on fire. Below are twelve questions: ten across those four areas, plus two on team structure, each with why it matters.

Metrics and KPIs (key performance indicators, the specific numbers used to judge whether the work is succeeding)

1. "What are the two or three metrics you'll actually judge my first six months against?" Aligns my effort with what's measured, rather than what merely looks good.
2. "Is there an existing dashboard or report showing the current baseline for those metrics?" Grounds any target I commit to in reality instead of a guess.
3. "Which of those metrics are actually inside my control, and which can I only influence?" A metric I am judged on but cannot move without three other teams agreeing is a target I should renegotiate now, not at the review.

Data and tooling

4. "What's the primary stack, and where does data quality or reliability break down today?" Surfaces known landmines before I inherit them silently.
5. "Which tools are the actual source of truth versus legacy systems people still half-use?" Avoids wasting early weeks mastering a tool the team is already abandoning.

Process and rhythms

6. "What's the meeting cadence, standups, planning, one-on-ones, and who actually attends?" Sets realistic expectations for calendar load and where decisions get made.
7. "How do decisions get made when the team disagrees, and who has the final call?" Clarifies decision rights (who is actually authorized to decide) before I need that answer under pressure.

Immediate problems

8. "What's the one thing that's been broken or blocked the longest?" Reveals the real priority behind the polished job description.
9. "What did the person previously in this role do well, and where did they struggle?" Sets a realistic bar and flags landmines without me having to rediscover them the hard way.
10. "What has been tried on that problem already, and why did it not stick?" Stops me from proposing in week two the exact fix that failed last year for reasons nobody wrote down.

Team and reporting

11. "Who do I report to day-to-day versus who formally evaluates my performance?" These can differ on matrixed teams (a structure where you have both a functional manager and a separate day-to-day project or product lead, each with real influence over your work), and the gap matters.
12. "How many people are on the team, and how is work currently split among them?" Shapes whether I'm stepping into an ownership role or a support role.

Trade-offs and a closing practice

Ask the hiring manager and a team lead separately where you can; their answers to "what's broken" often diverge, and the gap is informative. Don't ask questions the job posting already answered, and prioritize the ones most likely to change your decision or your first 90 days. A strong habit once you land the role: turn the answers into a short written role-expectations document you both sign off on, so priorities don't quietly drift a month later.

Direct answer

Business impact from data engineering (DE) work is best shown as a mix of operational metrics you directly control and business-facing metrics those operational improvements are supposed to cause, because leadership cares about the second but you can only fully defend the first with hard evidence. Label which is which when you present the list: of the five below, the first three are operational and sit entirely inside your control, cost savings is the one already denominated in the unit leadership thinks in so it is the business-facing headline, and satisfaction is a stakeholder-facing proxy you influence rather than own. An unlabeled mixed list invites someone to read a latency number as though it were a revenue number.

Five metrics

1. Time-to-insight (operational): how long it takes from an event happening to an analyst or dashboard being able to see it, for example cutting pipeline latency from a 24-hour batch to a 2-hour batch. Directly attributable, since you own pipeline latency end to end and can point to your own before-and-after monitoring.
2. Query latency improvement (operational): how fast common analytical queries run against your tables, for example a dashboard query that used to time out past 30 seconds now returning in 3 seconds after adding partitioning. Directly attributable via query-engine logs before and after.
3. Incident reduction (operational): fewer data-pipeline failures or data-quality incidents per month. Directly attributable from your own incident tracker, though the business effect, fewer wrong numbers reaching stakeholders, is harder to dollarize precisely, so state it as a count reduction rather than inventing a dollar figure you don't have.
4. Cost savings (business-facing): reduced cloud compute or storage spend from optimizing a pipeline, for example replacing an expensive full-table scan with an incremental load. Directly attributable if you can show the billing line item before and after, since infrastructure cost is a hard, measurable number.
5. Analyst or stakeholder satisfaction (stakeholder-facing proxy): a lightweight survey, or a proxy like falling average ticket-resolution time for data requests. The weakest of the five to attribute cleanly, since satisfaction is influenced by many things besides your pipeline work, so treat it as a supporting signal, not a headline claim.

Attributing changes to engineering versus other factors

Use a clean before-and-after comparison isolated to the specific change, comparing latency the week before and after one optimization ships rather than a quarter-over-quarter trend that could be confounded by data volume growth. Where another factor plausibly moved at the same time, like a cloud vendor price change alongside your cost optimization, separate out and net that confounder rather than claiming the full delta. For the softer metrics, be honest that engineering is a contributing factor among several, not the sole cause.

Worked example

Say a table scan powering a daily revenue dashboard used to take 45 minutes at roughly 40 compute-hours per run. After adding incremental processing, it takes 6 minutes at roughly 5 compute-hours per run: a 35 compute-hour reduction, which is 35 of 40, or 87.5% of that job's compute cost, holding data volume roughly constant across the comparison window. Quote it as 87.5% rather than rounding it down to 87%, since the one person guaranteed to redo the division is the reviewer whose trust the rest of the number depends on. That's the kind of number worth presenting, rather than a vague claim of "made things faster."

Trade-offs and pitfalls

Leaning entirely on operational metrics, which are easy to measure, risks looking disconnected from business value in a review. Leaning entirely on business metrics, which are noisy and multi-caused, risks overclaiming credit you can't defend. The sharpest pitfall is presenting a cost or time saving without controlling for a confound, like a pricing change, that actually explains most of the delta.

Owning a component means acting like its long-term steward, not just its most recent contributor: you know its weak points, you're the first call when it breaks, and you're driving what happens to it next rather than waiting to be told.

What ownership looks like across five areas

• Code quality: maintain a testing bar for the component, actively drive down a known recurring source of bugs, and keep its architecture documented well enough that someone else could reason about a change without asking you first.
• Documentation: maintain a runbook (a step-by-step guide for operating and debugging the component) and an architecture decision record, or ADR (a short document capturing why a significant design choice was made), so knowledge doesn't live only in your head.
• Incident response: be the primary escalation point when it breaks, write a blameless postmortem (an incident review focused on fixing the system rather than blaming the person) after any real incident, and track whether the same class of incident recurs afterward.
• Roadmap planning: proactively flag technical debt or scaling risk before it becomes an emergency, and propose, not just execute, the next quarter's improvements to the component.
• Mentoring: bring at least one other contributor up to speed on the component so it isn't a bus-factor-of-one situation, where only one person understands it well enough to keep it running.

Success metrics to track the impact

A downward trend in repeat incidents for that specific component over time, how long it takes to onboard a second contributor to real changes, PR review turnaround time within the component, and a qualitative signal like fewer escalations bypassing you straight to your manager.

Worked example

Owning a checkout service in a given quarter: write the runbook that didn't exist, add an alert for the exact failure mode that caused the last outage, mentor a teammate through their first on-call shift on the service, and get a scaling proposal you authored onto next quarter's roadmap instead of waiting for someone else to notice the risk.

Trade-offs and pitfalls

Ownership without documentation or mentoring creates a single point of failure (SPOF): if you're the only one who understands the component, you haven't reduced organizational risk, you've just centralized it in yourself. There's also a trade-off against over-scoping ownership into empire-building; a component is still one part of a larger system, and treating every adjacent decision as yours to control slows the team down rather than protecting it.