Picture a data engineer six months into a new job. The pipelines run, the tests pass, the warehouse is tidy. Then a Monday meeting turns sour: the sales director says revenue grew, the finance lead says it shrank, and both are holding charts built from tables this engineer maintains. Nobody’s code is wrong. Each of them means something different by “revenue”. That moment, uncomfortable as it is, is where one of the most underrated data engineering career skills begins: helping people agree on what their words mean.<\/p>\n
Let us stay with our engineer for a moment. After the meeting, they trace both charts back to source. Sales counts an order as revenue on the day it is booked. Finance counts it when the invoice is paid, net of refunds and excluding tax. Both definitions are defensible. Both have been used for years. Neither is written anywhere except in two SQL views with similar names.<\/p>\n
The tempting response is to pick a side or build a third view that “fixes” things. Our engineer does something else. They write a single page with both definitions side by side, the exact calculation behind each, a worked example of one order flowing through both, and a question at the bottom: which of these should the company call “revenue”, and what should the other one be called?<\/em> Then they send it to both leaders.<\/p>\n The reply takes a week, but it comes. Finance owns “revenue”. Sales keeps its number under a new name, “booked value”. The two views are renamed, the dashboards relabelled, and the Monday argument never happens again.<\/p>\n Nothing in that story required a new tool. It required someone willing to notice that a disagreement about numbers was really a disagreement about meaning.<\/p>\n Early in a data career it is natural to measure progress by technical depth: more orchestration patterns, faster queries, cleaner models. Those matter. But the people who become trusted senior engineers, analytics leads and data platform owners tend to share another trait. They make ambiguity visible and help others resolve it.<\/p>\n There are practical reasons this skill compounds:<\/p>\n This is why our DataOpsSchool learning paths, certifications and consulting work<\/a> treat agreed definitions as part of the DataOps operating model itself, sitting alongside testing, observability and governance rather than tucked away as documentation.<\/p>\n The first habit is hearing the problem. Words like “customer”, “order”, “churn”, “session”, “active”, “complete” and “on time” are almost always overloaded in a growing company. When two people use one of them in the same conversation and their numbers disagree, that is the signal. Experienced engineers learn to pause and ask, gently, “when you say active, what counts?”<\/p>\n The second habit is turning a verbal agreement into something durable. A useful entry is short: the term, one plain-language sentence, the exact logic or source, a borderline example, the owner, and the date. Many teams keep these in a business glossary that links terms to the people and tables behind them<\/a>. Others start with a shared page. The format matters less than the discipline of keeping one approved version.<\/p>\n The third habit is resisting the urge to own every definition yourself. Data engineers are often the people who notice the problem, but the business function that lives with the consequences should usually own the meaning. Finance owns revenue; customer success might own churn; product might own active user. Your role is to make the decision easy, make it visible and make sure systems follow it.<\/p>\n The fourth habit is technical again. Once a term is agreed, it should be findable where people actually work. That might mean descriptions on warehouse columns, tags in a data catalog where analysts search for trusted datasets<\/a>, or naming conventions that make the approved metric obvious. A definition nobody can find is barely better than no definition.<\/p>\n Consider a different scene. An analytics team promises a new churn model will be “done” by the end of the quarter. The data scientists deliver a trained model with good offline scores and call it done. The product team expected a working score inside the customer app. Leadership expected a weekly report on at-risk accounts. Three groups, three finish lines.<\/p>\n An engineer on that team, already burned once, proposes a small fix for the next project: a written “definition of done” before work starts, listing what will exist, where it will run, who can see it and who maintains it. It feels bureaucratic at first. By the second project, nobody wants to work without it.<\/p>\n That engineer did not get promoted for the model. They got promoted because projects they touched stopped ending in disappointment.<\/p>\n You do not need a senior title to start. Some low-risk ways to build the habit:<\/p>\n Notice too what the engineer did not do. They did not write a policy document or call a governance committee. They picked one recurring source of frustration, solved it end to end, and let the result speak. Small, complete wins like that persuade sceptical colleagues far better than any proposal for a grand glossary initiative, and they give you a template you can reuse the next time a word starts causing trouble.<\/p>\n Hiring managers for data roles increasingly ask about cross-team work. “Tell me about a time you resolved a conflict” is a common prompt, and a story about a contested metric is one of the strongest answers a data engineer can give. It shows technical tracing, communication, judgement about ownership and follow-through into systems.<\/p>\n Come review season, this kind of contribution tends to vanish, since what it produces is mostly things that stopped happening: arguments that no longer happen, rework that was avoided, reports that stopped contradicting each other. Capture those outcomes as they occur. A sentence like “aligned finance and sales on a single revenue definition, retiring two conflicting views” is concrete and memorable.<\/p>\n Return to our engineer from the first story. A year later, new hires are pointed to the glossary on day one. Dashboard titles reference approved terms. When a new metric is proposed, someone asks, by habit, “who owns this definition?” The engineer did not plan to become the team’s translator. They simply kept noticing when people were talking past each other, and kept writing the answer down.<\/p>\n That is a career skill worth building deliberately. Tools change every few years. The ability to turn a confused room into a shared understanding, and then encode that understanding in the data platform, stays valuable for an entire career.<\/p>\n","protected":false},"excerpt":{"rendered":" When two charts disagree, the real problem is often a word. Learn why agreeing on metric definitions is a data engineering career skill worth building early.<\/p>\n","protected":false},"author":6,"featured_media":4400,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[814],"tags":[],"class_list":["post-4399","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dataops"],"_links":{"self":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/4399","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=4399"}],"version-history":[{"count":1,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/4399\/revisions"}],"predecessor-version":[{"id":4431,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/4399\/revisions\/4431"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/media\/4400"}],"wp:attachment":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=4399"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=4399"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=4399"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why shared definitions are a career skill, not admin work<\/h2>\n
\n
What the skill looks like day to day<\/h2>\n
Listening for the overloaded word<\/h3>\n
Writing the definition down<\/h3>\n
Finding the right owner<\/h3>\n
Connecting meaning to metadata<\/h3>\n
A second story: the “done” that was not done<\/h2>\n
How to practise this skill early in your career<\/h2>\n
\n
Talking about it in interviews and reviews<\/h2>\n
The quiet power of agreeing on words<\/h2>\n