Text Is Data
8 of 14 · February 2026

Text Is Data

Text Is Data

I've written seven articles. About responsibility, about voice, about how I capture everything that's said, about why generic summaries are worthless, about the infrastructure, about knowledge as a prerequisite, about what one person can deliver. Most of the examples have been about software development — code, systems, technical delivery.

It's been about code. Absolutely.

But it's also been about exactly the same thing as everything else I do.

Code Is Conversation

When I talk with a developer about a code change, that conversation gets captured. The client's phrasing, the technical trade-offs, what was said between the lines about what's actually the priority. The transcript becomes source material. The code gets written. The code is text.

When I sit in a project meeting and we discuss timeline, delivery, expectations — that's the exact same process. The conversation gets captured. The transcript gets processed. The decisions get documented. The documentation is text.

When I have a sales call and the client describes their problem — same process. The verbal conversation gets captured. The transcript preserves it. The summary becomes the basis for the proposal. The proposal is text.

When the contract needs to be written, it's based on what was actually discussed. The contract is text.

When I talk with a team member about how things are going, what's working, what isn't — same process. With confidentiality around the content, but with exactly the same handling. The notes are text.

Code. Project documentation. Proposals. Contracts. Summaries. Meeting notes. It's all text. And text is data.

Data Can Be Processed

That's the insight that ties together everything I've written. Not that AI is a useful tool — everyone knows that by now. But that all professional work is fundamentally about text that can be treated as data.

The conversation is text after transcription. The code is text. The specification is text. The contract is text. The decision gets documented as text. The follow-up is text.

And all of that text — regardless of whether it started as a client call, a code review, a sales meeting, or a one-on-one — can be processed with AI. Summarized. Structured. Compared against previous data. Used as context for the next step.

The process I've described throughout this series looks the same regardless of what the text is about. Capture the conversation. Process the transcript. Review the output. Take responsibility for what comes out. Build on what was actually said.

It doesn't matter whether it's a code change or a sales call. It doesn't matter whether it's a project review or a one-on-one. The chain is the same. The responsibility is the same. The process is the same.

Why It Looks Like Separate Worlds

People treat writing code, managing projects, selling, and having one-on-ones as fundamentally different activities. Different tools, different processes, different people.

But from the perspective of "text is data," it's one and the same thing. What separates them is the content and the level of confidentiality — not the process.

A person who understands that — who treats all professional work as text that can be captured, processed, and used as data — that person doesn't work in separate worlds. That person works in a system.

And that system scales in exactly the way I've described: one person, with the right knowledge, the right chain, and full responsibility at every step.

Code wasn't just the example. Code is one of many forms of text. And text is data.

Was this helpful?