Last week I stood in Fenway Park and watched Phish turn a baseball stadium into a living room. This week I caught Oteil and Friends, and watching Oteil Burbridge play bass is watching fifty years of this music flow through one guy. He held down the low end for the Allman Brothers. He carried the Dead's songbook forward with Dead and Company. Now he leads his own band through all of it.

Two shows in two weeks, and the same thought kept hitting me both nights.

The Grateful Dead played roughly 2,300 shows over thirty years. The Allman Brothers ran for forty five years and survived losses that would have ended any other band. Phish is still going after four decades, and on any given night they will play a song they have played a thousand times and make it sound like they are figuring it out for the first time.

That is not luck. That is not magic. That is a system. And I think about it more than I probably should.

They Play the Bad Notes in Public

Phish takes real risks on stage. Every night. Sometimes a jam goes nowhere. Sometimes Trey flubs a lick in front of twenty thousand people. And the next night they get back up and take the same risks again.

Compare that to how most of us work. We polish everything in private. We do not ship until it is perfect. We treat mistakes like something to hide instead of something to use.

The Dead had a saying about this. Every mistake is just a doorway to the next idea. Jerry Garcia hit wrong notes constantly. He also turned more wrong notes into right ones than maybe anyone who ever played the instrument. He could do that because he was not afraid of the mistake. He was already listening for where it could go.

The only way to learn is to try. If you never allow yourself a wrong note, you are never going to find anything new either. You get safe work. Safe work is forgettable work.

Showing Up Is the Whole Trick

Here is the least romantic part, and the most important. These bands kept going by playing. Constantly. Through years when it was not cool. Through lineup changes, bad reviews, personal disasters, and stretches where the music honestly was not great.

The Dead were not fashionable for most of their existence. Phish broke up twice and came back. And the Allman Brothers set the standard for endurance nobody wants to match. They lost Duane Allman in 1971, right as they were becoming the best band in America. They lost Berry Oakley a year later, three blocks from where Duane went down. They kept playing. Broke up, reformed, broke up again, came back in 1989 and ran another twenty five years. They did not wait for inspiration or the right moment. They booked the tour and played the shows.

Creativity is not a lightning strike. It is a practice. The bands that lasted fifty years did not last because every night was transcendent. They lasted because they showed up on the nights that were not. The great nights only happen because the ordinary ones keep the machine running.

I have been building for the web for a while now. Flash sites, table layouts, a dozen frameworks that were going to change everything and then quietly disappeared. The tools never stopped churning. The habit of showing up and building the next thing is the only reason I am still here. Nobody remembers the glamorous years anyway. The unglamorous ones are where you earn your keep.

Play With People Who Listen

One more thing. None of these bands is a solo act with a backing band. They are conversations. The Allmans ran two lead guitars and two drummers, which should be chaos, and instead Duane and Dickey Betts invented a harmony language other bands are still borrowing. The bass player is allowed to take the song somewhere. The drummer can change the whole feel of a jam and everyone follows.

That is what I was watching at the Oteil show this week. A guy who has spent his whole career listening, now with a band built around it. The material moves between the Allmans catalog and the Dead catalog and it all fits, because the tradition was never about any one band. It was about how they played together.

That only works with trust. Trust that the people around you are paying attention. Trust that if you take a risk, someone will catch it and build on it instead of letting it die.

The Takeaway

Take your risks in public. Show up on the ordinary nights. Surround yourself with people who actually listen.

The Dead, the Allmans, and Phish are not just bands. They are proof that creativity is not something you have. It is something you do, over and over, for decades, with people you trust. Two nights in two weeks reminded me of that better than any business book ever has.

Now if you will excuse me, I need to figure out which show I am catching next.

Last weekend I took our development team up to camp for a retreat. We went to a rodeo. We did team building. We had fun. Some of it was conversations with the team about my role. Some of it was just me, up at camp, with room to think. That kind of quiet is hard to find during a normal week, and it's usually where the honest reflections happen.

What a CTO actually does is a fair question, because the answer keeps evolving. Here's the honest version: I say no a lot.

AI changed the math

We are moving fast into AI and the tools built around it. My team can build things better and faster than ever. Someone can spin up a working prototype in an afternoon that would have taken two weeks a few years ago.

That sounds like a dream. In some ways it is. But it created a new problem.

When building was slow, the cost of an idea was obvious. You had to justify weeks of work before anyone wrote a line of code. Now the build is cheap. The demo is impressive. And the real cost is hidden somewhere downstream.

So more of my job has become evaluation. What software, what services, what stacks earn a place in what we run. Not because the ideas are bad. Most of them are good. That's what makes it hard.

The no is almost never about the code

When I say no, it's rarely "this doesn't work." It usually works great.

The no is about everything around it. It doesn't fit our stack. It's missing a piece of information from the rest of the company. It solves a problem for one person but creates a maintenance burden for everyone. Nobody talked to the stakeholders who would actually live with it.

Building was never the bottleneck. Owning is the bottleneck. Somebody has to maintain that thing, secure it, integrate it, and fix it at 2am three years from now. AI made building cheap. It did not make owning cheap.

The PHP question

Here's a real example we wrestle with. We are experts at PHP. Twenty-plus years of it. We know Node too. So should we move to Node?

Maybe. The technology argument is easy to make. But changing a stack is not just changing a stack. It's changing workflows for people who have mastered the current one. It's trading deep expertise for shallow expertise and hoping you close the gap before it costs you.

Our debugging instincts, our deployment pipelines, our institutional knowledge. That's all part of the stack too, even though it never shows up in a framework comparison chart.

So the question is never "is Node good?" It's "are we eating our own efficiency to make the switch, and what do we actually get back?" Sometimes the answer is yes, move. Often the answer is that the boring, proven thing is still the right thing. Things don't need to be the latest and greatest to be the best.

Saying no without deflating people

This is the part I'm still working on. When you say no to a really smart person who just built something impressive, it can land like you don't care. Like the door is closed. That's the last thing I want.

What I try to do is show the ledger. A bare no feels like a verdict on the person. A no with the reasoning visible feels like a decision they were part of. Here's what this costs us downstream. Here's what's missing. Here's what would have to be true for this to become a yes.

Sometimes they come back and convince me. That's a win. That's exactly the kind of team I want. People who think for themselves, try things, make mistakes, and push back when they believe in something.

The job, as best I can describe it

My job is not to be the smartest developer in the room. It's to protect the whole system. The stack, the team, the clients who depend on what we run, and the efficiency we've spent years building.

Sometimes that means saying no to good ideas. It's a hard balance. But somebody has to read the whole ledger, not just the first column.

If you're a technical leader dealing with the same thing, I'd genuinely like to hear how you handle it. Especially the people side. The technology decisions are the easy part.

I grew up on the command line. My first machines were old Tandy computers running DOS, and there was no other way to use them. You didn't click anything. You typed. Loading a game, copying a file, formatting a disk, it all happened at a prompt. The CLI wasn't a power-user feature. It was how you made the computer work, period.

Then Windows and the Mac took over, and for the next thirty years the entire software industry worked on hiding that prompt. Prettier interfaces. Drag and drop. WYSIWYG editors. No-code platforms. The command line got pushed into a corner where only developers and sysadmins ever went. A black screen with a blinking cursor. If you didn't already know what to type, you were stuck.

Then AI showed up, and the terminal won anyway.

The numbers are hard to ignore

The clearest example is Claude Code, Anthropic's AI coding tool. It doesn't run in a slick web app. It runs in the terminal. The same interface we've had since the 1970s.

And it's the fastest-growing software product most of us have ever seen. It hit $1 billion in annualized revenue six months after its public launch, and $2.5 billion by February 2026, according to Reuters and Anthropic's own reporting. For comparison, Cursor, another popular AI coding tool, took more than a year to cross $500 million.

Usage numbers tell the same story. SemiAnalysis found that by early February 2026, Claude Code was authoring roughly 4 percent of all public GitHub commits, around 135,000 commits per day, and projected it could reach 20 percent or more by the end of the year. Anthropic reported that weekly active users doubled in the first weeks of 2026 alone, and business subscriptions quadrupled.

Meanwhile, the Pragmatic Engineer survey from February 2026 found that 73 percent of engineering teams now use AI coding tools daily, up from 41 percent a year earlier. At small companies and startups, Claude Code adoption sits around 75 percent. Three out of four.

Think about what that means. The hottest interface in software right now is a text prompt in a terminal window. Not despite being a terminal. Because of it.

And it's not just developers anymore

Here's the part that really gets me. I'm watching designers, marketers, and project managers open a terminal like it's nothing. People who would have laughed at you five years ago if you suggested they use the CLI.

Anthropic's own Economic Index research shows the shift. Coding is still the biggest use case, around 35 percent of conversations, but usage is spreading fast across other kinds of work. The top ten tasks made up 24 percent of all activity in late 2025 and only 19 percent by February 2026. The tool is diffusing outward, from developers to everyone else. Analysts covering the space say the same pattern showing up in engineering is arriving in marketing, finance, legal, and operations, just a year or so behind.

Non-developers aren't learning the command line. They're skipping the part that made it hard.

The interface was never the problem

This is the lesson, and it's one I've been preaching for years.

The CLI wasn't scary because it was ugly. It was scary because you had to already know what to type. Every GUI ever built was an attempt to solve that knowledge problem with buttons. AI solved it with language. You say what you want. It figures out the rest.

And once the knowing part was fixed, it turns out people are perfectly happy with a blinking cursor. Nobody misses the ribbon menus.

That should tell you something about how much of modern software is over-engineered. We spent decades stacking abstraction on abstraction, framework on framework, trying to make things "easier." The terminal is basically unchanged since the 70s. It does one thing. You tell it what you want, it does it. It outlived every trend because it's simple and it works.

Things don't need to be the latest and greatest to be the best.

What this means if you run a business

If you're a contractor or a business owner reading this, here's the takeaway. The tools your vendors and partners use are changing fast. Real fast. Development that took weeks now takes days. Teams in published case studies report development velocity gains of 2x to 10x after adopting these tools.

But here's what hasn't changed. Someone still has to understand what got built. AI can generate code faster than anyone can type it. It can't tell you whether that code is the right code for your business, whether it's secure, whether it'll survive the next platform update, or what breaks when something changes. Writing code was never the bottleneck. Comprehension was, and still is.

So when you're evaluating a digital partner, don't ask whether they use AI. Everyone does now, or will soon. Ask whether they understand what they're shipping. Ask who's accountable when it breaks. The tools got faster. The responsibility didn't move.

The command line won because it kept things simple and it worked. That's not a bad standard for the rest of your technology either.

Sources:

• SemiAnalysis, "Claude Code is the Inflection Point" (February 2026): GitHub commit share and adoption trajectory
• The Pragmatic Engineer, "AI Tooling for Software Engineers in 2026" (survey ran January 27 to February 17, 2026): daily AI tool usage and adoption rates
• Anthropic, Series G funding announcement (February 2026): Claude Code revenue, weekly active users, and business subscription figures
• Anthropic, Economic Index report (March 2026): usage diversification and task distribution data

I did not get into technology for a career. I got into it because I wanted to know how things worked. And in the early 90s, if you were a kid with a computer, the things you wanted to understand were games.

Type "Open Door"

If you grew up on Sierra games, you know the drill. King's Quest. Space Quest. Police Quest. Leisure Suit Larry, if your parents weren't paying attention. These games didn't hand you anything. You typed commands into a parser and hoped the game understood you.

"Look at tree." "Climb tree." "Take egg."

That parser was brutal. It wanted exact words in an exact order. Type the wrong verb and you got nothing. Type the right verb at the wrong time and you died. Sierra loved killing you.

Here's the thing nobody realized at the time: that parser was teaching us syntax. It was teaching us that computers are literal. That the machine does exactly what you tell it, not what you meant. That precision matters and vagueness fails.

That is programming. That is the whole job. The parser was a compiler with a sense of humor.

Before the Game Even Started

Sierra games taught you more before you ever saw the title screen. To play a DOS game in the early 90s, you had to earn it.

You edited CONFIG.SYS and AUTOEXEC.BAT by hand. You learned the difference between conventional memory, extended memory, and expanded memory because Space Quest IV would not run without enough of the right kind. You made boot disks. You figured out IRQ settings so your Sound Blaster would make noise. You memorized DOS commands because there was no other way to move around your own machine.

None of that felt like learning. It felt like the price of admission. But it built something real: a mental model of how a computer actually works. Files, memory, drivers, hardware. You knew what was under the hood because you had to reach in and touch it just to play a game.

Then Came the BBS

Somewhere in there, I set up a BBS in my house. One phone line, a modem, and a piece of software that turned my computer into a place other people could visit.

If you never experienced a BBS, here is the short version. People dialed your phone number with their modem. One at a time, because you had one line. They left messages, played door games, uploaded and downloaded files.

TradeWars 2002 was the big one for me. If you know, you know. A space trading game rendered entirely in ANSI text, played in daily turns, one caller at a time. You hauled cargo between ports, built up your ship, planted colonies, and schemed against everyone else on the board. Somebody would blow up your fighters overnight and you would spend the whole school day plotting revenge. Alliances formed. Alliances got betrayed. All of it playing out over weeks on a single phone line in my house.

Running the TradeWars game was its own education too. As the sysop I managed the game settings, reset the universe when it got stale, and watched how a handful of rules could create an entire economy and a social scene around it. That is systems thinking. I just thought it was fun.

Running a BBS meant you were not just a user anymore. You were the operator. You configured the software. You managed the file areas. You dealt with the kid who kept tying up the line. You learned what happens when your system goes down and people notice.

That was my first taste of running infrastructure. I did not know to call it that. But it was the same job I do today, just smaller. Something you built, that other people depend on, that has to work.

Why That Era Made Programmers

The early 90s had a specific magic to it, and it was not nostalgia. It was friction.

Computers back then were transparent by necessity. There was no app store. There was no "it just works." Everything you did required understanding a layer below the thing you actually wanted. Playing a game required understanding DOS. Running a BBS required understanding modems and serial ports. Copying a game from a friend required understanding disks and file systems.

The gap between "using a computer" and "programming a computer" was tiny. You were already in the terminal. You were already editing config files. Writing a batch file was a small step. Writing a QBasic program was one more. The machine invited you in because it had no way to keep you out.

Games were the motivation. Curiosity was the fuel. Friction was the teacher.

What's Out There for Kids Today

So here is the question I get, usually from parents: computers are sealed boxes now, phones even more so, so where does a kid get that same experience?

The good news is the on-ramps still exist. They just look different.

Minecraft is the BBS of this generation. Kids run their own servers. They install mods. They write command blocks and redstone logic, which is genuinely circuit design whether they know it or not. A kid managing a Minecraft server for their friends is doing exactly what I did with my BBS. Infrastructure, users, uptime, drama and all.

Roblox is where kids ship products. Say what you want about the platform, but kids are building actual games in Lua, publishing them, and watching real people play them. That feedback loop of build, ship, see people use it, fix what broke, is the whole job compressed into something a ten-year-old can do.

Scratch is the new QBasic. Drag-and-drop blocks instead of typed syntax, which purists complain about, and the purists are wrong. It teaches logic, loops, events, and variables. The syntax can come later. The thinking is the hard part.

Raspberry Pi is the new bare machine. Forty bucks gets a kid a computer that is transparent again. Linux, a terminal, GPIO pins you can wire things to. It brings back the friction on purpose, and friction is where the learning lives.

And AI is the new parser. Kids today are learning to talk to machines through prompts the way we learned through "look at tree." The lesson is the same one Sierra taught us: be precise, understand what the machine actually did, and don't trust output you can't explain. AI can generate code faster than any of us ever typed it. Someone still has to understand what got built. That was true in 1992 and it is more true now.

The Fundamentals Didn't Change

The frameworks change every couple of years. The fundamentals do not. What made a kid into a programmer in 1992 is the same thing that does it in 2026: curiosity, a machine that lets you poke at it, and something you care about enough to fight through the frustration.

For me it was a Sierra parser that killed me a hundred times and a phone line that tied up the house every night. For a kid today it might be a Minecraft server or a Raspberry Pi in a shoebox.

The tools are different. The discovery is the same. Give a kid a machine, give them a reason to care, and get out of the way. The only way to learn is to try.

HubSpot just learned an expensive lesson about trust. It took them four days.

On July 1, HubSpot quietly updated its terms of service. Buried in the fine print was a big change: data from your CRM could be pooled into a shared commercial dataset and used to enrich other customers' records. Business contact info. Company data. Email engagement signals like opens, clicks, and bounces. Even data you imported and cleaned yourself.

Here's the part that set people off. Everyone was opted in by default. If you didn't want your data feeding the pool, you had to find the setting and turn it off yourself.

The backlash was immediate. By July 5, HubSpot published a post titled "We Got This Wrong. And We Are Fixing It." They killed the terms change and promised that any future data sharing would be fully opt-in.

Credit where it's due. They owned the mistake publicly and reversed fast. That's more than most companies do.

But if you run a business, or you market for one, there are lessons here worth sitting with. Because this story is bigger than HubSpot.

What HubSpot Was Actually Trying to Do

The plan wasn't evil. It was strategic.

HubSpot was building a product called Contact Discovery, set to launch in August. The idea: let sales teams find and verify new contacts without leaving HubSpot. To power it, they needed a massive, constantly refreshed contact database.

And they were sitting on one. Hundreds of thousands of live CRMs, updated every day by real businesses doing real work. Your data entry. Your list cleaning. Your bounce handling. Pool all of that together and you have one of the freshest B2B datasets on earth.

The problem was never the product. It was the mechanism. Instead of asking customers to contribute, HubSpot changed the terms and flipped everyone's switch to ON.

That's not consent. That's a bet that you won't notice.

This Model Isn't New

Here's what most of the coverage missed. Plenty of companies already do this. They just do it out in the open.

ZoomInfo built its entire business on a contribute-to-access model. You get access to their database, and in exchange, their software reads contact data from your email. Apollo, Lusha, Seamless, and a dozen other tools run some version of crowdsourced contact data. It's the standard playbook in the sales data world.

The difference is that those are data companies. When you sign up for ZoomInfo, you know the deal. You're trading your data for theirs.

A CRM is different. A CRM is supposed to be a system of record that you own. You bought the software. You built the database. You paid your team to maintain it. When the vendor decides your database is now an input to a product they sell to everyone else, including your competitors, that's not a feature. That's a fundamental change to the relationship.

HubSpot tried to make that change with a terms update over a holiday week. Customers noticed. Good.

Why This Will Happen Again

Don't mistake this reversal for the end of the story. HubSpot said they still believe in a shared, continuously improving dataset. They're just going to relaunch it with clearer opt-in.

And the pressure that pushed them here isn't going away.

Contact data is getting cheap. Tools like Clay and Apollo are driving the price of raw B2B data toward zero. When the data itself is nearly free, the only lasting advantage is a dataset that gets better as more people use it. That's a network effect, and every software vendor with a large customer base is thinking about how to build one.

Which means every vendor with access to your data is looking at it and wondering what else it could be worth.

Your CRM. Your email platform. Your field service software. Your review management tool. All of them are sitting on customer data that you created. Expect more of them to ask for it. Some will ask nicely. Some will bury it in an update to the terms.

What This Means If You Run a Contracting Business

I work with home service contractors every day. HVAC, plumbing, electrical, roofing. And I'll tell you what I tell them.

Your customer list is one of the most valuable things your business owns. It took years to build. It's full of people who already trust you, already paid you, and will call you again if you stay in front of them. No lead vendor can sell you anything close to it.

Most contractors are not reading terms of service updates. They're running crews, quoting jobs, and answering phones. That's exactly why this matters. The businesses least equipped to catch a quiet policy change are often the ones with the most to lose from it.

So here's the practical advice:

Know where your customer data lives. Every tool that touches your customer list is a potential leak point. Make a list. It's shorter than you think.

Ask your vendors the direct question. Is my data used to enrich, train, or improve anything outside my account? A good vendor answers in one sentence. A bad one sends you to a policy page.

Watch for opt-out defaults. Any time a vendor makes data sharing the default and puts the off switch on you, that tells you something about how they see the relationship.

Work with partners who read the fine print for you. A good digital partner absorbs this risk. They watch the terms changes, they lock down the settings, and they flag the problems before you ever hear about them on the news. If your vendor hands that job back to you, that's a red flag.

The Bottom Line

HubSpot's reversal proves something encouraging. Customers still have power. Enough noise in four days killed a plan that took months to build.

But the direction of the industry is clear. Your data is the product now, and every vendor wants a piece of it. Opt-out is not consent. Defaults are not choices. And the businesses that protect their customer data today will be glad they did.

Real businesses are built on real relationships. Guard the list.

Sources and further reading:

• HubSpot Scraps Opt-Out Data Sharing Plan Days After Announcing It (CMSWire)
• HubSpot Spent 20 Years Selling Trust. It Took Four Days of Fine Print to Put It on the Line. (The State of Brand)
• HubSpot Data Pooling: What Changes on 4 August 2026 (Value Gravity)

If you've sat through a pitch meeting or skimmed any product strategy deck lately, you've heard the word "moat." It's everywhere. Network effects are a moat. Switching costs are a moat. Proprietary data is a moat. Your brand is a moat. Somebody on a panel is, right now, explaining why their AI wrapper has a "durable moat."

I use the word too. It's useful shorthand. But the constant repetition has started to make it feel like something you say to sound smart rather than something you actually have to earn. So let me push on it, and then tell you what our moat at Red Barn Media Group really is, because I think it's the least glamorous and most defensible kind there is.

The word is new. The idea is ancient.

Warren Buffett popularized "moat" as an investing concept decades ago, and he didn't invent the underlying idea either. He just named something businesses have always known: the question isn't whether you can win a customer today, it's whether you can keep them tomorrow when somebody bigger, cheaper, or louder shows up.

That's the whole concept. A moat is just the answer to "why won't this be easy to copy?"

Medieval guilds had moats; they controlled who was allowed to learn the trade. The railroad barons had moats; they owned the land the tracks ran on. The local hardware store that's survived three Home Depots opening nearby has a moat, even if the owner would never use the word. He knows every contractor in town by name and what they're building this season.

So when software people talk about moats like it's a recent discovery, it's a little funny. We've dressed up a very old survival instinct in venture capital clothing.

Why software made everyone moat-obsessed

Software made the moat conversation more urgent for a real reason, not just a fashionable one.

In traditional business, a lot of your moat came free from physical reality. Distance protected you. Shipping product and building stores is expensive, so a competitor couldn't appear in your market overnight. Geography did the defending for you.

Software deleted that. When your product is a URL, distance is zero. A competitor in another country reaches your customer as easily as you do. Distribution is nearly free. Copying features is fast. The cost of serving one more user rounds to nothing, for you and for the person trying to eat your lunch.

So in a world where the old physical moats evaporated, software people had to get deliberate about manufacturing new ones. That's the obsession. SaaS founders talk about moats constantly because SaaS is born without one. You have to go build it on purpose.

The moats everyone lists (and why most are shakier than they sound)

The standard menu goes like this:

Network effects. Your product gets better as more people use it. Real, powerful, and rare. A lot of companies claim it when what they have is just "a lot of users," which isn't the same thing.

Switching costs. Once a customer's data and workflows live in your tool, leaving hurts. Legitimate, but it cuts both ways. Customers resent feeling trapped, and "we're annoying to leave" isn't "we're worth staying for."

Proprietary data. The current favorite, especially with AI in the mix. But data is only a moat if it's hard to get, genuinely useful, and yours to use. A lot of "proprietary data" is none of the three.

Brand. Slow to build, hard to fake, underrated. But brand without substance is a logo, and customers figure that out fast.

Economies of scale. Works great until someone burns money to undercut you, which in software happens roughly every Tuesday.

These are real categories. But notice how many are things you assert rather than things you can prove. That's the buzzword trap: "moat" becomes a word you reach for to make a weakness sound like a strategy.

The real test

Here's the test I apply, to us and to everyone throwing the word around: a real moat is something your competitor can fully understand and still not replicate.

If knowing your secret lets someone copy it, it was never a moat. It was a head start. The hardware store's relationships, the guild's controlled training, our accumulated judgment: you can explain all of them out loud and your competitor is still stuck, because the barrier isn't knowing, it's doing the years.

So use the word "moat" if you want. I will. Just make sure you can finish the sentence honestly: "...and the reason a smarter, richer competitor can't copy this is _______."

If you can't fill in that blank with something real, you don't have a moat. You have a buzzword.