# If You Have to Ask Engineering for Every Report, We Should Talk Source URL: https://blueprintdata.xyz/blog/ask-engineering-for-every-report Published: 2026-11-03 Author: Marco Porracin Site: Blueprintdata Tags: self-service analytics, data modeling, data governance, analytics engineering, business intelligence ## Summary When every business question becomes an engineering ticket, the problem is not a lack of dashboards. It is a missing data model that gives people safe, governed access to company information. ## Article If you have to ask engineering every time you need a report or a number, we should probably talk. Not because engineers should never help with data. In a small company, asking the person who built the product is often the fastest way to answer a question. They know where the data lives, what the tables mean, and which edge cases matter. A request in Slack can quickly become a SQL query, a CSV, or a dashboard. That is a reasonable way to start. The problem appears when the shortcut becomes the operating model. Sales needs pipeline by segment. Finance needs revenue by product. Operations needs yesterday's volume. A manager wants to understand a sudden change. Each question joins the same queue as product work, incidents, integrations, and everything else the technology team owns. The company has data. It just cannot use it without asking for help one request at a time. The Ticket Is a Symptom It is easy to describe this as a dashboard shortage. Build more dashboards, the thinking goes, and people will stop asking for reports. That usually does not solve the underlying problem. A dashboard can answer the questions anticipated when it was built. The next question is often slightly different: Can we split this by region? Does this include refunds? Can we compare new customers with returning customers? Why does this total differ from Finance? If the meaning of the data still lives in an engineer's head, every variation goes back to engineering. The bottleneck is not the request process. It is the absence of a shared, reliable model of the business. Operational databases are designed to run products. A table may use internal status codes, store the current state instead of history, or split one business concept across several systems. That structure can be correct for the application and still be difficult for the rest of the company to use. Someone has to translate application data into concepts the business recognizes: customers, subscriptions, orders, revenue, campaigns, inventory, regions, and dates. When that translation happens inside an ad hoc query, it disappears as soon as the CSV is delivered. The next request starts from zero. Engineering Becomes the Human Semantic Layer When a company has not modeled its information, engineers compensate with context. They remember that test accounts must be excluded, which timestamp represents a completed order, and which service owns the latest customer attributes. That knowledge makes an individual report possible. It does not make data available to the organization. The pattern is familiar. A business user asks for a number. An engineer locates the sources, rewrites business rules that appeared in earlier queries, and delivers a spreadsheet or one-off dashboard. Nobody can easily inspect, reuse, or update the logic without asking again. Both sides lose. Business teams wait for answers and learn to limit the questions they ask. Engineers are interrupted by work that is important but rarely planned. Leadership receives reports that look precise but may use different definitions. The company becomes slower at learning from information it already owns. This is not an engineering performance problem. The technology team may be protecting production systems and sensitive data. The dependency exists because the company has not built a safe path around those constraints. Self-Service Does Not Mean Giving Everyone Database Access The obvious reaction is to grant more access. That can make the problem worse. Raw access is not useful access. A person can query application tables and still get a basic business question wrong by joining records at the wrong grain, counting duplicate events, or exposing personal information. Real self-service has boundaries. People should be able to answer appropriate questions from documented datasets with agreed definitions, clear ownership, and access controls that match their role. That requires several things working together: - Centralized data: Relevant operational systems are ingested into a platform built for analytical use. - Business models: Raw tables are transformed into recognizable entities and events with deliberate grains. - Shared definitions: Important measures such as active customer, completed order, and net revenue are implemented once and reused. - Documentation and lineage: People can understand what a field means, where it came from, and what depends on it. - Quality controls: Tests and monitoring catch broken pipelines, missing records, duplicates, and unexpected values. - Governed access: Roles, row-level policies, masking, and approved datasets protect sensitive information without blocking every legitimate use. - Usable tools: Analysts and business users have an interface appropriate to their skills, whether that is SQL, a BI tool, or a curated reporting layer. The goal is not to let everyone see everything. The goal is to make the right information available to the right people, with enough context to use it responsibly. Security and Access Are Part of the Design Companies often postpone self-service because their data includes personal, financial, or commercially sensitive information. The concern is valid. The conclusion that engineering must mediate every request is not. A governed data platform can be more secure than a stream of manual exports. Manual spreadsheets and CSV files spread across inboxes, shared drives, and local machines. Access is difficult to review, and corrected definitions do not update old exports. In a governed environment, access follows responsibilities. Finance can work with financial detail. A regional lead can see only the relevant region. Customer identifiers can be masked, while approved marts expose only the fields needed for analysis. Security should be enforced by the platform, not reconstructed in every request. Data minimization, retention rules, auditability, and ownership are easier to apply when information moves through known pipelines and curated models. Democratizing data does not mean weakening controls. Done well, it replaces informal sharing with explicit controls. How to Know the Dependency Has Become a Constraint You should start planning a different model when several of these are true: - Routine reports arrive through engineering tickets or Slack messages. - A new filter or breakdown requires someone to rewrite SQL. - Different teams receive different answers to the same business question. - The meaning of key fields is known by a few engineers but not documented. - People export data because they cannot explore it in the reporting tool. - Sensitive information is shared through manual files because no governed dataset exists. - Engineers avoid granting access because application tables are too complex or risky. - Leadership waits for recurring reports that could be generated from existing data. One request is not a platform problem. A recurring dependency across teams is. The clearest signal is not the size of the backlog. It is that people stop asking follow-up questions because getting the first answer took too much effort. The First Version Can Be Focused The alternative is not a company-wide transformation. Start with one business area where the dependency is frequent and the definitions matter, such as commercial performance, product usage, operations, or finance. A practical first version can look like this: - Inventory the recurring questions. Collect the reports, queries, spreadsheets, and definitions already used to answer them. - Choose the necessary sources. Ingest only the systems needed for that first domain. - Define the business entities and grains. Agree on what one row represents and how core concepts are calculated. - Build tested models. Publish clean, documented datasets instead of exposing application tables directly. - Apply access policies. Identify sensitive fields and grant each audience only what it needs. - Connect the consumption layer. Give users a dashboard, exploration interface, or SQL workspace based on how they actually work. - Validate with real questions. Ask the original requesters to reproduce the reports and explore the next question themselves. Engineering should still be involved. Its role changes from answering each question to building and operating a reliable path to answers. Decisions about sources, identity, access, performance, and reliability become part of the platform. Business definitions become visible and reviewable instead of buried in one-off queries. A Good Question Should Not Become a Queue Asking engineering for a number is not a mistake. It is often how a company discovers what information matters. But if every report requires an engineer, the organization has not truly made its data available. It has concentrated access, definitions, and context in a small group of people who already have other work to do. The answer is not unlimited access and it is not another pile of dashboards. It is a modeled, documented, tested, and governed information layer that lets employees use company data within clear boundaries. Your technology team should build systems that enable the business. It should not have to act as the business's reporting API. If this setup sounds familiar, talk with Blueprintdata (/#contact). We can identify the first high-value domain, design the right access controls, and build a data foundation your team can use without turning every question into a ticket.