Before the Bill Comes Due

The message hit my inbox at 10 PM on a Thursday. Our IT partners - the same people who had handed out the API keys in the first place - had flagged our token spend to the budget owner in our division, who had no context for any of it. They forwarded the thread my way, giving me the chance to step in before anything got cut off. Good partnership and good process, doing what they're supposed to do.

Nobody told me when the keys would be deactivated. I assumed Friday morning. I worked to three.

How We Got Here

Claude got into Verizon the way most powerful tools get into big companies. Quietly, through the technical teams closest to the work. One of our major IT divisions brought it in first. I don't know which one specifically - there are several of them, handling different things at scale. The program had been running there for a while before the rest of us came across it.

That division had posted a Confluence page on their internal wiki. It described how to request access and was probably aimed at people inside their own org. One of the front-end developers on my Content Delivery team came across it anyway, followed the link to a Slack channel that didn't scope requests by organization, and asked for a key. He got one.

The first key grant might have been incidental. The grants that came afterward were the result of a deliberate choice by the IT leadership behind the program. Leave the door open for a while. Make access available to the broader community. See what value would manifest when a powerful new tool was put in people's hands without policy gates. I would learn later, when I got in touch with their leadership chain, that they were cooking with fire on this. Intentional. Forward-thinking. Genuinely committed to helping Verizon learn what this technology could actually do. The conditions for everything that came next started with their choice to leave the door open.

The process tightened a notch over time. By the point I got my key, the confirming email mentioned that the spend would route back to your VP. But the underlying offer hadn't changed. Open keys. Use them however you wanted.

I had been doing a lot of this kind of work at home already, on my own time - building sophisticated systems for myself and learning what the technology could do. When I got a key at work and the option to run Claude Code, I brought a chunk of my workflow system with me and got going. The lens shifted faster than I expected. The work at home had been ambitious but personal in scope. At work the frame changed: this was a daily-use foundational tool, in the same class as email or a web browser, and the question stopped being "how do I use this" and became "how do we use this together, and what does the work look like when we do?"

So I went wide. I taught the people on my team. I built out the ecosystem with the ones who had the technical skill to help. And I encouraged adoption everywhere I could reach, because the value of a tool like this compounds with breadth. A handful of people using this tool is a productivity story. A working community using it is a change in how work gets done.

Why Looseness Mattered

Big companies have a default response to anything genuinely new. Control. Restrict. Mitigate. Build the policy first, then let people in. That instinct works well for stabilizing what you already understand. It does not work for figuring out what you don't.

This technology is too new for anyone to know what good looks like yet. Too new to know what it can do at scale, where it breaks, what kinds of work it transforms versus what kinds it merely speeds up. Before the rules are written, the worst thing you can do is lock down the people who would have written them. You set the wrong expectations. You build assumptions into the foundation that the next eighteen months will prove wrong. You shut the aperture before you have learned what aperture you actually need.

The period of looseness is not a bug. It is how the rules get written intelligently. You give people room to try things, fail visibly, and find use cases nobody would have predicted from a policy document. You learn what governance the technology actually requires by watching where it goes when nobody is telling it where to go.

The Flywheel

Real work started happening. Daily utility, the kind that is invisible until you try to imagine the day without it. Communications drafted faster and sharper. Analysis done in a fraction of the time. Material produced that we would not have had the time to make otherwise, because the friction had dropped.

At the same time we were building bigger things. Custom software. Information portals. A collaboration server where people could share their work and let the system know what everyone was doing. Several major projects, all running in parallel with the daily utility, because once you have a foundational tool in your hands you stop thinking in single-use-case terms.

The spend graph started pointing up.

The Bill

Visibility was what set off the alarm. The amount itself was modest by our scale, but nobody who owned the budget had heard about any of it. From their vantage, the response was automatic. You can't keep spending against a budget when nobody has signed off.

Our IT partners handled it the way good partners do. They escalated to the budget owner through the proper channel and looped me in on the thread early enough that I could step in. Due process and partnership, working the way they should.

The gap was mine. I had built something with real institutional weight, and I had not done a good enough job projecting that weight upward to the people who needed to know about it. Awareness is not sponsorship. Some people knew. Not enough of them knew, and not the people who could have put their hand up when our spend got noticed at the budget layer.

There is a sacred obligation in this kind of moment, regardless of how the gap got there. If you are using company resources, you owe the company an honest accounting of what you used them for and what came out of it.

The Site

I had two jobs to do by Friday morning. Save the keys. And finally do the kind of upward briefing on the work I should have been doing for months.

A deck wouldn't do it. A memo wouldn't do it. The case needed to be a thing you could open and look at, with the actual work behind it, organized so a decision-maker could move through it in twenty minutes and come out with a clear picture.

So I built a site, and worked on it until three in the morning.

The Work

The first section was the work itself - every project I had built, every project my team had built, every project anyone in the broader internal community had uploaded to our collaboration server. Full history. Real artifacts. Links so anyone could follow the trail.

What made it possible to assemble all of this overnight was a piece of system work I had done earlier in the year. I had built our setup so that every project preserved its own context as it happened - prompts, conversation arcs, iterations, outputs, working notes, all captured alongside the work itself. This kind of intact preservation isn't yet built into the tools we use. I had wired it in deliberately. So when the moment came overnight, the record was already there, waiting to be read. I wasn't reconstructing anything.

What came out of pulling it all together was something I would call the distilled digital truth of what we had built. Comprehensive in a way conventional reporting cannot match, because the source data was the work itself. Accurate, because every prompt and every output had been preserved as it happened. Honest, because there was no narrative layer to add - the trail spoke for itself.

There was real substance in there. I am proud of that. There was nothing to hide and nothing to dress up. The work was the case.

The People

The second section was the people. Product Managers, Process Managers, Digital Merchandisers, Front End Developers, and more - a real cross-section across the division and beyond it. People who had found their way to this technology and brought it into their work. A community had formed quietly, pollinating each other's projects and sharing what they had learned. The site showed it as it actually was.

The first pass had thin spots. The data the site pulled from our project artifacts was rich on what people had done - who had worked on what, when, with what outputs - but it was thin on who those people actually were. The site could tell you that one of our developers had built a specific tool. It couldn't tell you anything about who that developer actually was - their role, their working style, their strengths.

Earlier in the year, I had been doing a different piece of work: curating rich, actionable people profiles from my work corpus. Role. Working style. Communication preferences. Key strengths. The projects each person had led and contributed to. The kind of texture that lets you actually understand someone.

So I ran every name from the site through those profiles. The second pass came back fully fleshed out. Each person's role, working style, and strengths in view. Their work with this technology placed in the context of who they are and what they bring. That payoff was a gift from earlier work.

The Public Engagement

The third section was the public-facing work. I had been writing on LinkedIn about working with AI inside a big company, mostly on my own time, as personal thought leadership. I am a Verizon employee of some standing, and when I publish in my name, the company is in the frame whether I want it to be or not. I am mindful about that. I am proud of where I work, grateful to be there, and committed to not putting Verizon's reputation at risk through anything I publish.

At the same time, Verizon is the largest telecommunications company in the Western Hemisphere. That comes with a responsibility to weigh in on what is happening to work right now. To have both hands on the wheel. To do our part to make this work out as well as it can for society while also realizing the benefits for ourselves. The site put that frame on the public engagement directly, alongside everything else.

The Value

The fourth section was the value. I gave the numbers, framed conservatively. By any reasonable estimate, what we had produced would have cost more than ten times the spend through conventional development. The figures were traceable. They were not constructed to flatter the story.

The bigger point about value, the one I wanted the decision-makers to hold onto after they had moved past the spreadsheet, was this. You don't measure enabling technologies the way you measure products. You don't measure email by counting messages sent. You don't measure web browsing by counting URLs loaded. The value of these tools is one step removed from the product being sold. It shows up in the work that becomes possible because everyone has access to the tool, and the line from spend to outcome is honestly part felt experience and part math. You still have to talk about ROI. You just have to use the framework you apply to other enabling tools.

The Outcome

The site landed.

Direct circulation to the people who needed to make the decision. Wider notification to the daily stakeholders and technology partners, framed honestly. Real concerns were raised, here is how we addressed them, here is where we are. I owned the gap. I did not deflect.

Our IT partners agreed in good faith to hold off on any deactivation. The discussion happened over the next few days. The budget owner came to the table with full context. The division accepted the work as legitimate, the spend as supportable, the value as real.

Then they did the reasonable thing. They said we have to govern this. Token caps per key. Budget visibility. Guardrails to be iterated on as we learn more. Of course. It could not have been any other way. The moment you have moved from "is this a thing" to "yes, this is a thing," you need the institutional infrastructure to support it. The work continues. The value continues. The aperture stays open enough for innovation, with the kind of scaffolding that lets the organization actually plan around it.

The looseness doesn't last forever. That is part of the design. You get to keep what you built during that period, on the condition that you accept the structure that makes it sustainable. I will take that trade.

If We Had to Do It Again

What I would do the same. Push adoption wide and early - the value of a tool like this compounds with breadth, and the work gets meaningfully better as the number of people doing it grows. Build daily utility and major projects together rather than in sequence; the two reinforce each other in ways neither can manage alone. Document everything as you build it, because the moment will come when the audit trail is the case you have to make, and you will not have time to construct one overnight. Build out the kind of people-profile system that lets you describe everyone's work with full texture, and do it before you need it. A community is more than a list of names, and the day comes when you need to show it.

What I would do differently. Project the value upward earlier and more often. Awareness is not sponsorship. Some people knowing about your work is not the same as the people who control the budget understanding why it has to keep running. Find the budget owner. Find the head of the division. Tell them what you are doing and why before they have to ask.

Treat surprise as the problem to solve. Once budget owners have context, they can manage. Without context, they have to react.

When governance comes up, bring something to it. Share what you think would actually work, what would create friction, and what isn't really a risk in your case. The people designing the controls have a hard problem in front of them, and the perspective from inside the work is useful to them.

What's Coming, and How to Land the Plane

If you are earlier in this arc than I was that Thursday night, the moment is coming, even if the path looks nothing like mine. The way this technology enters companies varies enormously. Some places get access wide open the way we did. Some get it locked down from the start. Plenty land somewhere in between. The specifics of when and how the reckoning arrives will reflect where your company sits on that spectrum. The underlying moment doesn't change. Sooner or later, someone with budget authority is going to want to understand what is being spent and what is being produced, and the proof points, discussions, decisions, and solutions involved in answering that will look essentially like what I went through. Your only currency in that moment is honest, complete evidence of value.

If you are already in the moment, on the receiving end of the message, speed matters most. Show the work rather than describe it, and audit everything you can find - all the projects, all the artifacts, all the people, the whole community. No cherry-picking; the honest version is almost always stronger than the polished one. Send the case directly to the people who need to decide, and send the broader audience a summary of what was raised, what you are doing about it, and where things stand. Be honest about the situation, whatever it actually is.

The bill arriving is a marker. It comes differently for every company - sometimes early, sometimes late, sometimes loud, sometimes quietly through a forwarded email. The work it asks of you is the same. Take it seriously, and be ready when it comes.