Business Thursday – Page 4 – EduDataSci – Educating the world about data and leadership

Information Governance: The Backbone That Unifies Data, AI, Applications, and Analytics

Information governance (IG) is the strategy, accountability, and control system for how an organization collects, classifies, uses, protects, shares, retains, and disposes of information across its entire lifecycle. It is:

Scope‑wide: Covers structured data, unstructured content, model artifacts, code, dashboards, and records (including legal/records management and privacy).
Lifecycle‑aware: From intake and creation → active use → archival → retention/disposition and legal holds.
Outcome‑driven: Balances value (insights, automation, personalization) with risk (security, privacy, ethics, legal/regulatory).

Where data governance focuses on data as an asset, information governance focuses on information as a liability and an asset—linking value creation with lawful, ethical, and secure handling.

You Can Own a Data Product Without Writing a Line of Code

If you’re on an operations or business team and someone just asked you to “own the data product,” you might be thinking: I don’t code—how could I own it?
Good news: owning a data product is a leadership role, not a coding job.

Think of it like being a product owner in other fields:

Software product manager: sets the roadmap and defines success while engineers write the code.
Consumer hardware lead: chooses features and quality thresholds while factories assemble devices.
Marketing campaign owner: decides audience and outcomes while creative and media teams execute.
Publishing editor: shapes the issue and deadlines while writers and designers produce.
Construction owner’s rep: defines scope, budget, and acceptance criteria while contractors build.

In every case, the owner doesn’t run the machinery. They own the outcomes: what gets built, why it matters, who it serves, how “good” it needs to be, and how it changes over time. Data product ownership is the same. You set direction, make trade‑offs, and keep everyone informed. Others handle the pipes, queries, and platforms.

What’s different with data is simply the medium: it behaves like a service. Your “product” is a reliable, permission‑aware way to answer recurring questions. Your promise is about freshness, accuracy, and clarity, not lines of code.

Digital Workers, the White Space, and How to “Hire” One (with the Right Partner)

Every organization has white space: important work that lives between teams and across systems, is almost always evidence‑bearing, and—despite its value—rarely reaches the top of the backlog. In software engineering, that’s the unglamorous backbone of quality: keeping documentation and runbooks current, sustaining full test coverage (beyond unit tests), and validating against standards (security, accessibility, SBOM/licensing). In manufacturing, it shows up as traceability and shipment evidence (SPC, PPAP/FAI, calibration certificates) and keeping control plans/PFMEA in sync with engineering changes. In education, it appears as standards alignment of curricula, accessibility/privacy checks across LMS content, and intervention follow‑through after assessments. These jobs cross many systems, require judgment, must leave an audit trail, and are perpetually “important but not urgent”—perfect territory for delegating to digital workers: software teammates that live in the seams, move work to done, and attach the receipts as they go.

“To effectively delegate these tasks they need knowledge, access, and some intangibles.” (Nathan Lasnoski)

A digital worker earns real delegation only when three things are in place: knowledge (trusted sources, rubrics, examples), access (the right tools and permissions under guardrails), and the intangibles of a good teammate (when to act vs. ask, tone, and norms). With that foundation, a coaching worker can also serve as worker‑as‑judge—applying explicit rubrics, pulling evidence across systems, returning a pass/fail or “needs work” with a brief rationale, and providing an easy appeal to a human. The payoff is fast, fair, actionable feedback that feels like a senior reviewer on call 24/7—something frontline teams welcome.

Data Mesh Isn’t Just for Tech Companies

If you’ve skimmed headlines, it’s easy to conclude that data mesh is a Silicon Valley thing—something streaming apps and fintechs use to wrangle petabytes. That mental model sells a lot of tools, but it misses the point. Data mesh is first an operating model—a way to organize people, responsibilities, and guardrails so data can be produced and used where the knowledge lives. That matters just as much (and often more) in organizations whose mission is not building software: manufacturers, hospitals, universities, public-sector agencies, retailers, utilities, and nonprofits.

Improvement Science on Microsoft Fabric

Turning small, theory‑driven tests into compounding results

Improvement science is simple and powerful: start with a clear theory of change, run a safe test, study the data, then adopt, adapt, or abandon. The challenge isn’t running one test—it’s running hundreds of small tests, keeping their intent and results visible, and scaling what works without losing the thread.

Microsoft Fabric is a strong fit because it lets you keep the learning system (ideas, theories, PDSA cycles, decisions) right next to the evidence system (measures and run charts). Below is a high‑level pattern that puts improvement science at the center, with examples from manufacturing and oil & gas.

Citizen Data Analysts, Citizen Data Scientists, and Citizen Developers—What We Mean (and How They Work Together)

If you’ve been reading along here, you know our north star is putting data to work—safely—where decisions actually happen. Three personas keep showing up in that mission: Citizen Data Analysts, Citizen Data Scientists, and Citizen Developers. They’re adjacent, not identical. Here’s how we define them, how they differ, and how to enable each without creating chaos.

Quick definitions (with Gartner links)

Citizen Data Analyst (CDA)
A domain expert who turns governed data products and a semantic layer into decisions using self‑service BI (dashboards, KPI views, ad‑hoc analysis). Not a Gartner term; it’s our practical label for the power user of curated data.

Citizen Data Scientist (CDS)
A business user who goes beyond visualization to prototype models with guided/augmented tools. Gartner’s definition is often quoted as: “a person who creates or generates models … but whose primary job function is outside the field of statistics and analytics.” See Gartner: Citizen Data Scientist for the glossary entry; a commonly quoted rendering is captured here.

Related Gartner context: augmented analytics “also augments the expert and citizen data scientists by automating many aspects of data science [and] ML.” (Gartner)

Citizen Developer (CD)
A business user who builds apps/automations on approved low‑code platforms. Gartner is concise: a citizen developer is “a persona, not a title or targeted role.” See Gartner: Citizen Developer.

Conway’s Law for Data Teams

Two Dashboards, One Truth

On Monday, Maya—head of a seven‑person data team—watched two dashboards disagree.

The executive dashboard showed $11.2M in MRR. Sales’ dashboard said $10.6M. Both pulled from “the warehouse.” Both refreshed nightly. Neither was “wrong”; they just measured different things.

Maya didn’t control how Sales Ops or Marketing were organized, who they reported to, or which tools they bought. She controlled only her data team—its models, interfaces, and operations. Yet the warehouse had clearly taken on the shape of the company’s communication patterns.

Conway’s Law, without asking permission, had moved in.

Foundational + Derived Data Products in a Data Mesh

A data mesh is a sociotechnical approach to analytical data that decentralizes responsibility to business domains while standardizing the way data is produced and consumed. It’s grounded in four principles: domain ownership, data as a product, a self‑serve data platform, and federated governance. In practice, it asks each domain team to publish data as a product—discoverable, trustworthy, and operable—while a common platform automates cross‑cutting rules (access, lineage, quality, security).

Zhamak Dehghani frames a data product as an architectural quantum: the smallest independently deployable unit that bundles data, code, metadata, and policy, with a versioned contract and a clear interface (APIs or governed views). Treating both foundational and derived products as quanta is the key to decoupled evolution without breaking interoperability.

Improvement Science for Business Leaders: A Practical Playbook for Better, Faster Results

Most executives know Lean, Six Sigma, and Agile. Improvement science is the disciplined backbone behind those methods—a way to get measurable gains by learning quickly in the real world, not just in the boardroom. It’s been refined for decades in healthcare and education, but its core ideas translate cleanly to sales, operations, CX, finance, HR, and product. Here’s what it is—and how to start using it immediately.

Managing Data Platform Projects the Agile Way—and Hitting Your Milestones

One of the things I’ve been thinking about lately a lot is how you formalize the type of project management that is necessary in data platforms, and what you need to do differently compared to software development projects. I brought in a collaborator, one of the best customer success managers I know, to talk about how to do this correctly.

Agile absolutely works for data platform projects, but you need a lightweight way to lock in critical choices without slowing teams down. Architectural Decision Records (ADRs) provide that spine: they capture why you chose a direction, what you rejected, and the consequences—so you can move fast and keep delivery predictable. Combine ADRs with vertical slices, data contracts, quality gates, and observable pipelines, and you can ship in short cycles while meeting real dates.