Engineering embedded with a customer: their data, their constraints, and a problem nobody has specified yet.
11 published across 3 topics.
Shipping inside someone else's organisation: competing stakeholders, being the only engineer, and handing over what you built.
The rounds look familiar but the scoring moves: a forward deployed engineer loop grades what you notice in messy data, whether you narrow a vague problem before building, whether your design fits a customer's operating capacity, and whether you can explain and push back in front of non-engineers.
Treat reluctance as a rational response to inheriting on-call burden rather than as resistance to change: find out what it costs them, transfer ownership through work they do themselves while you are still there, and get the acceptance recorded by whoever committed their capacity.
It moves the constraint from what you can build to what they can maintain: choose the stack their team already runs, cap the number of new concepts you introduce, and treat every clever abstraction as a maintenance debt they will pay after you are gone.
Stop negotiating between opinions and get the disagreement written down as two named decisions with their consequences, then push it to whoever owns the budget; as an outsider your leverage is that you can make the conflict visible without being a party to it.
Undocumented schemas, restricted access, no staging environment, and data that disagrees with what you were told.
Build the data profile and a validation report first, not the dashboard. Read every column as text, infer types from evidence, show the customer what you found within the first hour, then load accepted rows idempotently into a staging table with a rejected-rows file that explains every exclusion.
Pull a bounded, representative extract into an environment you control and develop against that, keeping production for read-only verification under agreed limits, and treat every write path as something proven against a restored copy before it runs anywhere near live.
Read the data rather than the DDL: profile every column for cardinality, null rate and value distribution, use foreign-key-shaped joins to test relationships you suspect, and confirm each conclusion against a report the business already trusts before you build on it.
Segment the nulls before drawing any conclusion — by date, source system, record type and creating process — because a null rate that clusters is a documented business path nobody mentioned, while one spread evenly is usually a genuine capture defect.
Turning a vague business problem into a shippable increment, and deciding what not to build.
Separate a disagreement about the mechanism from a disagreement about the goal, then test your objection cheaply rather than argue it: a week spent proving the request will not move the number is usually worth more than either refusing or complying in silence.
Decide on the prototype's foundations rather than its polish: if the data model and the correctness boundaries are sound, hardening is cheaper and keeps the users you have, and if they are not, no amount of testing and monitoring will make it safe to keep.
Convert the sentence into a named decision somebody makes today, find out how that decision is made now and what a better one is worth, then ship the narrowest thing that changes it — and say out loud what you are deliberately not building.