Technology Business or a Business That Uses Technology?

Over the last few years of working with different companies, I keep coming back to the same observation: there are really two types of companies out there. The first is a technology business. The second is a business that uses technology. Knowing which one you are changes almost every technology decision you make, and right now, with AI on the table, it matters more than it ever has.

Here's the short version. A technology business builds its identity around the software or hardware itself; the technology is the product. A business that uses technology has some other core value, selling food, moving packages, treating patients, and technology exists to help it reach that goal. Most companies are the second type, and there is nothing wrong with that. The problem I keep seeing is that second-type companies are adopting AI at first-type speed, without the structure that first-type companies spent decades building.

---

What is a technology business?

Think of your Apples and your Netflixes. These companies pride themselves on the technology itself. The software, and in some cases the hardware, is the core, and everything else gets built around it.

Tesla is a good example of how strongly a company can hold this identity. Tesla positions itself as a technology company rather than a car company, and you can see it in where the attention goes: full self-driving, robotics, software. The cars, in that framing, are the vehicle (literally) for the technology.

If you're this type of company, you probably already know it. Your engineers are the product team. Your roadmap is a technology roadmap. This post is mostly not about you.

---

What is a business that uses technology?

This is most companies, and I'd argue it's most of the companies that matter to the everyday economy. They have a specific core value, and they use technology to supplement it.

Tyson isn't in the software business. They want to sell you chicken. Technology helps them run the freezers, automate parts of the supply chain, and understand where things come from and where they're going. But nobody at Tyson confuses the software for the product.

UPS might be the even better example, because logistics sounds simple at the top: get this one package from New York to Los Angeles. Underneath that, technology is answering a hundred questions. What's the best route? Did the customer pick standard shipping or next-day? Truck, train, or plane? And once it lands in Los Angeles, which of the five drivers at that location has the route that covers that street? The technology is doing enormous work, but the goal was never the technology. The goal is the package arriving.

If your company looks more like Tyson or UPS than like Netflix, you're the second type. So is almost everyone. That's not a weakness. It only becomes a weakness when you make technology decisions as if you were the first type.

---

Why does the difference matter right now?

Because AI just handed second-type companies a very affordable way to move like first-type companies. Businesses everywhere are automating processes and building agentic workflows, and a lot of them are having a genuinely good time doing it. Things that used to require a big technology investment are suddenly within reach.

Here's the part I keep running into, though. First-type companies spent years building the structure that makes fast technology adoption safe: review practices, documentation habits, QA discipline, people whose whole job is deciding how the technology gets used. Second-type companies mostly never needed that structure, because their technology moved slowly. Now the technology is moving fast and the structure isn't there.

I see it in the hiring, too. A company brings in tech workers, some with ten years of experience, some with three, and expects them to organize the whole effort. But most developers are builders, not organizers. That's not a knock on developers; I am one. Speaking as one, I can tell you a lot of us are notoriously bad at documenting anything, and I've worked with developers who flat-out refuse. The building skill and the organizing skill are different skills, and companies keep hiring for one while assuming they're getting both.

And as the team grows from one or two people to three or four, the original vision starts to blur. Not because anyone is doing a bad job. The people you hire have their own lives and their own goals, they do their best work, and at the end of the day they go home. Someone has to hold the whole picture together, and in a second-type company, that role often doesn't exist at all.

---

What should you do about it?

First, just answer the question honestly: which type are you? If technology is genuinely your product, build like a technology business, with everything that implies.

If you're a business that uses technology, then use it, enthusiastically. The tools available right now are a real opportunity, and sitting them out has its own cost (I've written about what deliberate AI adoption looks like). But treat the structure as part of the adoption, not something you'll add later. Decide who owns the technical decisions. Make documentation and review part of how work gets done, not a thing developers are guilted about. And if nobody inside the company can hold that role yet, that's a solvable problem: it's exactly the gap embedded product engineering leadership exists to fill for a defined period, so the structure gets built and someone on your team learns to own it.

These are working thoughts from the companies I've seen, and your situation might be different. But if you take one thing from this: knowing which type of company you are isn't a philosophical exercise. It decides how much structure your next technology decision needs to come with.