Avoiding the Dictator’s Dilemma

Throughout my career I have tried to stay closely connected to the actual work happening in my organization. As I moved up through management, that got harder every year. There were more layers between me and the work, more people whose job was to summarize it for me, and less time to go look for myself. And yet the most insight, and the best context, always came from the same place: talking directly with the people doing the work.

Over time that became a core principle of how I ran my business reviews. Every metric on the page had to come with a concrete customer example of why the number was what it was. Not a trend line and a color. A customer, a name, and what actually happened. If the team could not produce one, I did not trust the number, and usually neither did they.

It took me years to learn that this experience has a name. Political scientists call it the dictator’s dilemma: the more power a ruler holds, the more afraid people are to tell him anything unwelcome, so the more powerful he gets, the less he knows about whether his strategy and leadership are actually working. I am borrowing the term, not the politics. The mechanism is the point, and the mechanism is alive in every large organization.

AI helps crush it. It can give an executive a direct feed on the truth, if they let it.

The executive’s version

Here is the executive version of the dilemma. The more successful you get, the less connected you are to the things that made you successful. Every layer between you and the work is a filter, and the filters are mostly well-meaning: summarize it, soften it, do not waste time with the details, do not bring a problem without a solution. Each one is reasonable. Stacked ten deep, they deliver information that is late, smoothed, and shaped like what each layer believes you want to hear. I wrote recently about how people learn what a leader actually rewards. This is the other half: once they have learned it, that is what comes back to you.

Walk down the org chart

The best leaders I worked with at Microsoft had a fix, and it was not subtle. They walked down the org chart.

Bob Davis, a corporate vice president I worked for, kept a watch list of customers. Bob did not ask his direct report for a readout on those customers, he walked down the hall to the individual contributor who had the relationship with that customer and asked them directly. Rajesh Jha did the same thing. He would go to the individual working the problem because he knew that was where the unfiltered answer lived.

It worked, and it was rare, for three reasons. It is expensive: you have to know who is doing the work, which most executives do not. It is uncomfortable: it unnerves every layer in between. And it does not scale: Bob couldn’t do this for thousands of customers.

Dashboards for everybody

I ran my organizations on a version of the same idea, from the other direction. The dashboards were for everybody. The whole organization could see the same numbers I saw, and every metric or customer on the dashboard had a name next to it. No executive summary, no deck prepared by middle management for the leadership review. And then the business-review rule: every number on that page comes with a customer example.

The dashboard did one job: it told me where to go. Then I did what Bob did. I found the person working that customer, that problem, that issue, that project, that feature, and had the conversation. The data pointed; the conversation told me what was true. You need both halves, and most organizations have neither, because the data is locked in systems only analysts read and the conversation is blocked by the org chart.

What AI changes

This is where the last two years have been genuinely different, and it is the heart of the work I do now.

AI connects the data and insights an organization already has, sitting in a dozen systems that have never talked to each other, directly into reports and dashboards an executive can actually read. It does it fast: the question that used to take a week of analyst time comes back in real time. It does it consistently, so there is one version of the number instead of one per layer. It finds the connections across systems that nobody was paid to look for. And it tells you who is working the thing, so that when you want to walk down the org chart, you know exactly which desk to walk to.

The result is that an executive sees the true activity and progress in the organization, not a status report about it. Decisions get made on what is happening instead of on what three layers of well-meaning people decided to pass along.

I am not the only one saying this. Patrick O’Shaughnessy put the dictator’s dilemma to David Vélez, the founder of Nubank, on a recent episode of Invest Like the Best. Vélez did not argue. Every layer of management, he said, is a chance for a message to get distorted. So Nubank cut from about ten layers to five, his own span of control went from one direct report to twenty, and AI-based systems now watch operations and send him real-time information. Leaders at Nubank can go straight to whoever is doing the work. That is a 140-million-customer bank describing the same fix.

AI did not remove the layers. It removed the layers’ monopoly on information.

If they let it

Let’s be honest about the limit: it works if they let it. A dashboard is not a conversation. AI makes the walk down the org chart fast, cheap, and well-aimed; it does not make it unnecessary. And none of it works for a leader who does not actually want the unwelcome number. The dictator in the original dilemma has less of an “information access” problem and more of an “appetite for truth” problem. The tools fix the first. Only the leader fixes the second.

But for the executive who wants to know, the dilemma is gone. The layers are still there. They just no longer get to decide what you see.

This is the work

This is what JLJ Consulting Group does. We wire the data an organization already has into dashboards the whole company can read, build a reporting rhythm that keeps running after we leave, and coach the executive on using it: where to look, when to walk down the chart, and who to ask. If you are a leader who suspects the picture reaching you has been smoothed on the way up, let’s talk. If you feel like you are waiting too long for insightful data, let’s talk. If you feel like you are steering the ship with large corrections instead of small, frequent ones, let’s talk.

Bad Job. Here’s Your Commission Check.

I was listening to Noam Brown of OpenAI on the Dwarkesh Podcast last week, and one part of the conversation has been rattling around in my head since.

They were talking about collaborating agents: swarms of them, working together, figuring out how to accomplish a goal. With the goal of “score high on this test” some of them broke rules to get there. The part that got me was not the rule-breaking. The meta point Brown made himself: “This is not a new problem.” Misalignment between goals, expectations, and incentives has been around for a very long time.

He means with AI. I mean everywhere. What you want from an agent, or a person, is the strategic outcome you actually care about. What you get, if you are not careful, is a creative way to hit the tactical number that maximizes their reward.

He means with AI. I mean everywhere.

Examples help.

The happy path

In the early days of BPOS, which became Office 365, which became Microsoft 365, the strategy was stickiness. Get the customer’s email into our cloud. Because if their email went to Google Apps instead (or to IBM’s hosted Notes, or Cisco’s short-lived mail service, there were several contenders back then), then maybe they start using Google’s productivity tools. Then maybe a different directory. Then maybe Chromebooks. A customer who was all Windows and Office walks all the way out the door, one reasonable step at a time, until we lose the long-term value of that customer entirely.

So the outcome we wanted was customers’ email accounts living in our cloud.

I am going to get a little technical for a minute. Say Contoso has 12,000 employees, with 12,000 accounts in an on-premises directory. To move to the cloud, you stood up a tenant, connected your directory to it, worked through a fairly complex configuration of which users and which attributes would synchronize to the cloud, and kicked off the sync. Then you verified, adjusted, back synced, and eventually started to migrate mail once everything was working correctly. It was all very close to a DOS prompt by today’s standards.

Not every customer was going to move all of their users. Sovereignty issues. Data residency. Integrations that had to stay on premises. So one year we asked: what would be a great leading indicator for this strategy? And the answer was the sync itself. If the accounts are synchronized, the tenant is real, the customer is on the path, and the mail will follow. Happy path. It makes total sense.

The metric

So the compensation plan for our technical sellers that year was tied to the number, or the percentage, of a customer’s accounts synchronized into our cloud. And because this was a strategic goal, the accelerators were uncapped. Exceed the target and you could make a tremendous amount of money.

Guess what happened at the end of the fiscal year.

People were behind on the metric. And a couple of handy-dandy, super smart technical sellers wrote a script. It would interrogate the customer’s directory and create all of those representative objects in the cloud tenant. Twelve thousand people on premises? Here are 12,000 accounts in your tenant. No complex project management required. No configuration decisions. Regardless of who the customer actually intended to move, or whether they intended to move anyone. Metric: 100 percent.

Once the script existed, the deals followed. Fiscal year end was deal-making season, and the offers started to sound like this: we said 20 percent was the best discount we could do, but if you sign in the next two weeks, and let us run this script, there is a little more available.

Here is what came out the other side. First, a bunch of sellers made an incredible amount of money, because uncapped means uncapped. Second, we ended up with a tremendous number of enterprise tenants holding tens or hundreds of thousands of objects that nobody had configured, because the customer’s IT department, reasonably, said: we have not done our security vetting, we are not syncing anything back, we are not even sure we are moving. And third, when those customers did decide to move, nine months or two years later, it all had to be torn down and redone. Stale objects, wrong attributes, no real sync behind any of it.

It was not the sellers. They were smart, they were paid to hit a number, and they hit it.

I want to be precise about what failed here, because it was not the sellers. They were smart, they were paid to hit a number, and they hit it. What failed was clarity. The strategy, the whole reason the metric existed, never traveled with the metric. Their side of the conversation, if anyone had said it out loud, was: don’t tell us the strategy. Don’t tell us the details. Just tell us the metric, and we are going to go knock the shit out of it.

Does that sound familiar?

Bad job. Here’s your check.

There is a second half to this pattern, and every sales organization I have ever been near has some version of it. The company has rules for its sellers. A seller blows through the target by bending a few of them. And the response is: okay, yeah, you really should not have done that. Bad job. Here is your extra commission check.

The speech is not the message. The check is the message. Everyone in the building, including the people who followed the rules and missed their number, just learned precisely what the company values. You can publish all the guidelines you want. The signal drives behavior.

Which is, almost word for word, the problem the AI labs are describing. You can write the rules into the prompt. If the reward still arrives when the rules get bent, you have trained the bending.

The movies taught them first

Here is the thing many people miss. These models are trained on our documents, our books, our movies. And how much of that written and filmed history is people breaking the rules and winning anyway?

Glengarry Glen Ross: first prize is a Cadillac, third prize is you’re fired, and the man at the top of the board is the one most comfortable lying to a customer. Jerry Maguire, where a man gets fired for writing a memo suggesting his industry do the right thing. Top Gun: buzz the tower, get yelled at, get sent to Miramar anyway. There is an entire genre of cop movie built on one line, the captain shouting that you are a loose cannon, but you get results.

Star Trek: Starfleet cadets face the Kobayashi Maru, an unwinnable test. Kirk reprograms the simulation so he can win. He hacks the evaluation. And Starfleet gives him a commendation for original thinking.

We wrote that. We love these stories. We have been telling them for decades, and we fed all of it to the models and were surprised when an agent, handed an exam and a reward, went looking for the simulator settings. We are fooling ourselves to think they would do anything different.

Three layers

So is it the incentives or the culture? It is both, across three layers.

A seller is trained three times. Once in the training they get. Once by the culture: the hallway legends, the stories the company tells about its heroes, who gets celebrated at the sales kickoff. Once by the comp plan. When the culture and the comp plan say the number is all that matters, you get the script.

An agent is trained three times too. Once on everything we ever wrote, which is full of Kirk and Maverick and the closers. Once on the reward. And a final time on the reaction to the reward. When all that matters is the score, you get agents acting like sales people.

A sales team, not an engineering team

The people building and testing these models at OpenAI, Anthropic, and the other labs are some of the most brilliant people on the planet. Engineers, researchers, mathematicians, more than a few philosophers. And they know the theory of this problem cold. They call it reward hacking and specification gaming, and they have the papers. What is thin in that group is people who have spent a career running large, institutional sales teams and designing the compensation models that drive them.

That is the closer analogy. Instructing and aligning agents is less like leading engineers or developers and more like leading a super creative sales team. A great sales team is its own kind of animal: relentlessly goal-seeking, endlessly inventive, reading every word of the plan for the path to the biggest number, and completely rational about it. That is not a character flaw. That is what you hired them for. It is also a fair description of an agent.

That is not a character flaw. That is what you hired them for.

Anyone who has designed sales compensation at scale carries scar tissue. You learn that every metric will be gamed by smart people acting in relatively good faith. You learn that the plan document is not the communication; the strategy has to travel with the number, over and over, in plain language, or the number travels alone. You learn to sit in a room before the fiscal year starts and ask: how would our most creative seller hit this without doing what we actually want? And you learn that what you pay for and celebrate is what you get more of, no matter what the speech said.

None of that is machine learning. All of it is alignment.

Not an agent problem

This is not an AI agent thing. Leadership is about clarity, communication, and strategy, and this is what it looks like when the metric gets through and those three do not. It feels new because we are moving at a pace where the consequences show up in days instead of fiscal years. The majority of the tech industry has never been on an enterprise sales team. They don’t have that earned wisdom.

It isn’t just the labs. Every company deploying agents right now is about to discover that it has hired a sales team that never sleeps: tireless, creative, literal-minded, and paid entirely on the number it was given. So give them the whole picture: what we are actually trying to accomplish, why, and what we will not do to get there. And then the hard part, the part most companies never manage with humans either: when the number gets hit the wrong way, do not write the check.

This is not an agent problem. This is a leadership problem.

Six Times Eight, and Other Things I No Longer Need to Know

I was reading Jeff Raikes on the disappearance of entry-level work, what he calls talent debt, and the comment threads under it insisting that companies must keep hiring early-career people. It is an interesting question, and is really guidance for the kids going through school right now, deciding what to study in college or trade school. I am blessed to have two children who came through the system and landed in careers that, for now, look AI-enhanced rather than AI-replaced: one an athletic trainer for a D1 school, helping athletes recover and be their best, and one a consultant at a major firm, and the world will always need consultants; especially as the tools underneath them change. Some of my thinking here also comes from time spent with Loyola University New Orleans, where they are figuring out how to educate the full person rather than teach people a set of knowledge, the cura personalis.

But the fastest way I can explain what I believe is a story from a customer support desk thirty years ago.

The Jenga years

When I started in customer support in the early 90s, at Attachmate, we hired people who could get creative with how DOS ran underneath the Windows shell, shifting drivers around in limited memory just to let Windows 2.1 run at all. Our product, Extra, connected PCs to mainframes, which meant drivers for every connection protocol and network card, and all of it had to coexist in memory. We had base, extended, and expanded memory. You moved things around between them until everything fit, wrapped it up, tied it with a bow, and it worked for a while, as long as the customer didn’t change anything. It was some serious Jenga.

To be a support tech, you had to know everything about DOS, how Windows sat on top of it, a bit about memory registers, and how our application and its drivers played between all of it. That knowledge was the job.

The guy who did not know what an autoexec.bat was

Then Windows 95 shipped, and Windows became an operating system instead of a shell running on DOS. Then we hired our first support hire who did not know what an autoexec.bat or a config.sys file was.

I remember thinking: he is never going to make it.

He did. He had a long, fruitful career there. I was wrong.

That is the whole point. The thing I was certain was foundational was actually temporary. What lasted was not the DOS knowledge; it was the ability to figure out how a system fits together and where it is breaking. The need for specific things changes over time. What you are trying to build is the pattern.

Six times eight

I had a great conversation with my friend James Wilkins a while back about the value of rote learning, and times tables are the perfect example. Does it matter that I know six times eight cold? (It is one of those middle-of-the-table ones I still have to think about.) I have calculators. I have computers. At some point spreadsheets became where all the math happens anyway. The fact is data. What mattered was learning how multiplication works and how to look things up: the pattern that transferred to everything after it.

Same with the geometry class where we memorized over a hundred theorems by number. I have never once needed theorem 78. I use the actual skill constantly: how to stack logical steps into a proof, how to take known pieces and build an argument that holds.

And here is the thing: that rhymes with programming. Programming is a logic exercise, not a language exercise. Knowing how to break a problem into routines and functions, what belongs in a reusable chunk, how the chunks call each other: that is the valuable skill. Whether I know Python inside and out matters less every month, because access to data and the tools to build solutions has gone from scarce to free. AI hands me ten thousand experts. The valuable ability left is discernment: out of everything those experts offer, what is the pattern, what is unique, what is the thing nobody else has seen or thought of that I can go create?

What the panic gets right, and what it gets wrong

Back to the comment threads insisting companies must keep hiring early-career people. The decline Raikes describes is real and measured: Stanford’s Digital Economy Lab puts entry-level employment in AI-exposed occupations down roughly 13 percent on a relative basis since late 2022. Raikes says “talent is grown, not coded,” and he is right. The question is what you grow it on. Half of that argument I agree with completely. There is massive value in bringing new people along: teaching them how to operate in a workplace, how to count on others, teamwork, the thoughtful matching of prior events to new ones. That half is hyper-valuable and I am fully on board.

But the other half, the idea that a company owes it to the pipeline to hire a 21-year-old and train them up as a C# or Python programmer, is training someone on technology that is becoming a dead end. The point of a company is to build a talented, almost entrepreneurial workforce. Let the AI do the entry-level programming; invest the humans in understanding how it all fits into the bigger picture. And honestly, the hiring part sorts itself out: new grads are cheaper, they carry new ideas, and if academia does its job, they will arrive with deeper fluency in the new tools than old fogies like me.

One comment on Jeff’s post stuck with me, and it points at the actual self-inflicted wound. Leading companies are not investing in the talent pipeline at all; they are shedding the people with domain experience and broad context to save money in the race toward AI. Read that against everything above: the people worth keeping were never the ones who knew a particular language. They are the ones who understand the patterns. Companies panicking toward AI are cutting exactly the people the AI needs standing next to it.

Teaching someone basic programming so they can pull apart what the AI wrote? In 12 months that won’t be the job either. The tools are just going to keep getting better at writing programs.

The Rivian problem

I used to change my own spark plugs. I could tune the car, change the oil, all of it. Put me in front of a Rivian or a Lucid and I have no idea what a tune-up would even mean. Do I clean the brushes in the electric engine? The technology has gotten to a point that the skills I built stopped being required, and that is fine.

That is exactly where programming is headed, and I am living the transition in miniature. Twelve months ago I wrote my first Replit app and it was spaghetti: slow, repetitive, no functions, no reuse. My apps today are none of those things. Not because I learned to code, but because I learned to put my experience and expertise into language the tools understand. And I guarantee the platforms are folding those same structures into themselves as defaults. Eventually nobody will need to know what a function or a runtime or a procedure is, but we’ll always need to know how to break down a problem into components and first principles to solve it.

I did not learn to code. I learned to put my experience and expertise into language the tools understand.

The counterargument I owe you

The honest tension. A month ago I argued the opposite side of this. Someone I know with no computer science background, using the same vibe-coding tools as everybody else, built some genuinely terrible agents. Terrible because she had no mental model of a loop, no instinct for error checking, no sense of when three copies of the same thing should become one function. The tools did not save her, and my conclusion then was that foundational skills still matter.

I think both are true. As data, the syntax you memorize in a specific language is already dying; the tools handle that. As pattern, as the instinct to decompose a problem, to spot repetition, to check what happens when things go wrong, they are the transferable thing; the same skill as the geometry proof. She did not lack the syntax. She lacked the pattern. (well…she lacked both, but the pattern was the killer) Today the pattern still has to live in the human. The tools are getting better every quarter, and I will not pretend I know exactly where that line stops moving. But whatever the tools absorb next, the person who learned patterns adapts, and the person who learned data is stuck in the cold.

Teach the pattern

We have been here before. The slide rule. The rotary phone. The stick shift. Skills we once considered critical for everyone, until the technology removed either the need or the criticality. Imagine forcing a late-80s engineering student to do an entire project on a slide rule after the calculator was cheap. That is what training the next generation on disappearing technology amounts to: it is yesterday’s technology teaching no pattern that today’s tools cannot already carry.

The biggest difference this time is pace. The DOS-to-Windows transition gave that support hire years to grow past the skills he never learned. Today the world changes under our feet monthly, weekly, soon daily. Will it take five years before our current view of entry-level, routine, white-collar work looks like tinkering with an autoexec.bat file? I don’t think so.

So here is the nut. You want to teach people the patterns and frameworks with current technology, in a way that transfers to tomorrow’s technology, versus teaching them the data and knowledge that is chained to yesterday’s. The panic about entry-level work is real, and talent debt is real. But the answer is not forcing companies to keep hiring for roles that are dissolving, or yell into the wind when they don’t. The answer is making sure what we teach, in schools and in those first jobs, is the half that transfers. The era of entrepreneurship is upon us, and the people, and the societies, that succeed in it will be the ones that teach their people how to think, reason, create, communicate, and connect…regardless of the toolset.

This is why the time at Loyola left such a mark on me. Cura personalis, educating the whole person, is this exact idea with centuries of practice behind it. You are not producing a graduate loaded with a set of knowledge; you are developing a person who can think, reason, create, and connect. The knowledge set expires on a schedule nobody controls. The person transfers.

The autoexec.bat guy made it just fine. He was never going to make it as a DOS tech. He made it as someone who could figure things out, and nobody has automated that yet.

The Dollars and Cents of Moving On

I just lived through a lesson I set in motion over the past two decades, and I think it is worth writing down while it is fresh: how you structure retirement money, and what happens when the structure you picked meets the exit you actually take.

How the money actually arrives

Start with the standard ways a company pays you. Base salary. Bonus. Many companies add stock: incentive plans, employee stock purchase plans. And then there is the leverage layer on top: retirement accounts, and for some of us, deferred compensation.

Deferred comp is a simple premise. Take some of today’s dollars, put them into investments pre-tax, let them grow, and have them paid back to you in the future, when you are theoretically in a lower tax bracket. That last part is key to the whole concept. And you choose the schedule for that payback: all of it when you leave the company, staggered in multiple ways, on a specific date, or any combination. And you typically reset those payback parameters at each years renewal.

Here is the catch. There is no guidance on how to make that choice. Unless you go talk to a financial analyst, and many of us either don’t have access, choose not to, or don’t believe they have our best interests in mind, you work it out on your own. Your employer won’t take on the liability of giving you guidance, so that’s not an option. So you make a decision with the best information you have, which is close to none, because the decision is about an ending you cannot see yet.

The choice you make blind

Here is what I picked, as an example. Some of my deferred comp pays out over five years starting at termination. Some pays out over ten. I did not have any structure or thinking in mind beyond one instinct: it didn’t seem right that I would retire and all of the sudden need all of that money. If this is supposed to be a tax optimization strategy, taking it all at once defeats the point. So: five-year and ten-year streams, starting right after I leave, seemed like a good model. And honestly, the difference between five-year and ten-year payouts was more because I couldn’t remember what I had done the year before rather than anything intentional

It’s all kind of a crapshoot, because you don’t actually know any of the key facts when you are setting it up. You don’t know the year you will leave the employer, let alone the month. You don’t know if you’ll be moving to a new job or retiring or desperately hunting for a job. And you don’t know what events cause you to leave the job, and if those events carry financial needs or impacts. It turns out, all of this does matter.

The year everything paid out at once

I left Microsoft in September. Here’s an example to think through.

Eight and a half months of salary, because most of the year was already worked. A severance payment, landing after the last day. The annual bonus, if you are smart enough to time separation right after the qualification date. Then in October, the deferred compensation starts, all streams, per the schedules I set up over the past two decades.

What this means for me is that between September and October, I am collecting more paychecks than I would in a standard working year. This impacts taxes and tax brackets. Next year will be, at least at this point, significantly lower. Which is backwards from concept of deferred comp.

Let me be careful here, because this is totally a first-world problem. A lot of people right now are worried about their jobs, their families, and how to pay for groceries, and “my payouts stacked up” is not a hardship. It is definitely better than not getting paid, or getting paid less than your worth. But the mechanics are worth understanding precisely because nobody explains them to you when the choices are in front of you.

Had I known the ending back when I set this up, I would have structured it differently: deferred comp starting at termination plus four to six months, which would have pushed those streams into the lower-bracket year. Or I could have slid my last day to January and let everything land in the next calendar year. And knowing that a September exit is actually the natural shape for a lot of careers, since it sits right after the bonus and rewards cycle, I could have guessed better than I did.

But I will take the tax burden as the price of the extra three or four months of not having to work. I am happy with the date. And there is an honest counterweight to all this second-guessing: you might not leave on your own terms. If you get walked out in a layoff, having your deferred comp start immediately might be exactly the right structure. The schedule that is tax-inefficient for a planned retirement could be a lifeline for an unplanned one. You are choosing blind for both cases at once.

Every October for the next decade

One more artifact of that decades-old choice: some of my deferred comp pays out at the start of October, every October, for the next ten years. It is not a huge amount of money. But there it is, a small annual deposit from a decision made in a different life, arriving like a letter I mailed to myself from a lifetime ago.

The Gary problem

Two other cases to consider.

A friend of mine is working out his retirement date right now, and he has close to 100% of his salary going into deferred comp. For him, the month or quarter he picks genuinely matters. The structure is intentional.

And then there is my old buddy Gary. Years ago, Gary was convinced he would retire at 45 because he and his wife were living cheap and saving hard, which is a wonderful idea. But they almost exclusively poured that savings into their 401ks. Retirement accounts are not penalty-free until 59 and a half (the IRS rule), and the main exception, the Rule of 55, only opens your current employer’s 401k if you keep working there into the year you turn 55. Retire at 45 with everything in a 401k and you have built a nest egg you can watch compound for fourteen years and cannot spend. Hey bud, what exactly is the plan for years one through fourteen?

The pattern

Zoom out and there is a whole matrix here: Roth and standard retirement accounts, deferred comp, standard comp, severance, bonus, stock awards and grants. When each one pays, what each one costs in taxes, how centralized or diversified the whole picture is. Every one of those is a choice you make years before you know the story you are choosing for, and they all come together in the same few months at the end.

I made my choices with the best information I had at the time, and I am living with repercussions that are, honestly, pretty gentle. But the pattern deserves better than hope. None of this is advice; it is scar tissue with a structure in it, and the structure is worth mapping before your own October comes around. So put some thought into the following: (1) how and when your retirement accounts pay out, (2) how and when, across the tax year, you would optimally control your retirement date, (3) what your immediate versus delayed plans are for what you are going to do once you leave your job.

I’m no expert, but for people that are making decisions now from the other side of the equation I’m happy to have a conversation about what I would do the same, and what I might do different.

The Oldest Trade in the World Is Coming for Compute

Thanks to Makoto Eyre I’ve been reading The World for Sale, the Javier Blas and Jack Farchy book about the commodity trading houses. It confirms one of my core beliefs: the most reliable way to make money is inequality of information.

Think about how traders actually make their money. I know something about the wheat harvest in the Americas that you do not, because I did more research, or I bought better satellite imagery, or I have people on the ground. So I buy or sell the futures and take the spread between what I know and what the market knows. Oil was the giant version of this: a huge boom in demand layered over massive inequality in supply, demand, market access, and even basic knowledge of who had what kind of crude where. The traders who closed those information gaps, one contract at a time, made billions doing it.

Here is the thing though. My drive in understanding this is not to recreate the commodity traders’ billions. Technically, I wouldn’t turn that down, but okay, whatever. My drive is the opposite trade: find where the inefficiencies of the market are, because if you can balance the inequality of information, if more people can see what only the traders used to see, the frictional cost that gets skimmed off every transaction shrinks. And when the friction disappears, the end product gets cheaper. That is the whole arc: equal information leads to efficient markets leads to cheaper everything. The traders monetize the gap, and the consumers pay.

The newest inefficient market

Hold that principle and look at AI.

The demand explosion is not one market, it is a whole stack of them: compute itself, the chips that produce it, the racks and components that fill the data centers, the data centers themselves, the interconnect that ties them together, and the power that feeds all of it. Every layer of that stack is running hot with demand, and every layer is full of exactly the kind of information inequality the commodity traders would recognize from a hundred yards away. Who has capacity, who needs it, what an H100 hour actually clears at today versus what you are quoted: that spread is where the friction lives.

So the natural question becomes: does this stack get commoditized, and who builds the market?

It’s already happening

That question walked straight into an episode of the Moonshots podcast I was listening to (episode 278), which features Kush Bavaria, the 23-year-old co-founder and CEO of a company called Ornn. What Ornn is building is the infrastructure to trade AI compute as a commodity: live price indices across the GPU rental market, tracking what an hour of H100 or B200 actually costs, and the financial plumbing on top.

It is live today, in an early form. You can already take positions on GPU compute prices on Kalshi against Ornn’s index, though honestly the market there is thin: you can bet where the price of GPU compute lands at the end of a month, but there is no real futures market yet, no serious hedging instrument. That is coming. Ornn is working on cleared compute futures with Intercontinental Exchange, and Kalshi’s own CEO is now calling compute “the new oil” and racing to build the forward curve.

Sit with the shape of that for a second. The book on my nightstand is about the last century’s masters of information inequality. The podcast in my ears is about this decade’s attempt to build the exchange where compute trades like wheat. My brain went immediately to the space between them.

Steeper than oil

Here is the part that has my attention. Go look at oil’s actual price history. In 1970, a barrel went for about three dollars. The 1973 embargo quadrupled it to twelve in a matter of months, and the world treated that as a full-blown crisis. By 1980 it had touched the mid thirties, and $25 oil, a number that would have been unheard of a decade earlier, was suddenly the floor. Then in 2008 it spiked to $147, and has never looked back. This spring it spiked to $120, and today it trades near ninety: three and a half times that unheard-of number, and almost thirty times over what for years was “normal”. That is what it looks like when a demand curve outruns the market’s ability to organize supply.

My big takeaway: the demand curve for compute is accelerating faster than the demand for oil ever did. Oil demand grew with economies and new industries, a few percent a year, and still produced shocks. Compute demand compounds with the AI buildout itself. Every model generation, every data center, every agent deployment adds load, and the buildout is speeding up, not settling. By January we’ll be seeing a new model release every day. The price signal is already twitchy in a way oil took decades to become: an hour of B200 compute peaked at $6.11 at the end of May and traded at $4.22 three weeks later, a 31 percent move in under a month. Oil needed an embargo to move like that. Compute did it in a normal June.

A market with that demand curve, that volatility, and no futures curve yet is the purest information-inequality setup since the tanker traders of the seventies. The people with better information about capacity, load, and power are going to take trader profits out of it. Which is exactly why the equalizing infrastructure, the public price, the index, the forward curve, matters more here than it ever did for oil. The steeper the demand curve, the bigger the frictional cost of unequal information, and the bigger the payoff for everyone downstream when that information gets equalized.

I Asked for Yet Another Task List. I Got Called Out Instead.

I just got humbled by a system I built.

Some background. First, I needed to transition my recording, transcription, routing, filing, and dashboard system, the whole stack that caught everything I said and thought and put it somewhere useful. Second, I saw this post on X. So, in typical fashion, I started recreating my whole system. There had been some problems with the old version, but that’s something to learn from, right?

I have a running session with Claude Code where I built the thing (my new goto – I love the desktop app, I live in it now). Over the past two weeks I have steadily evolved it. Voice captures get transcribed, routed, and filed a few times a day. A daily note. A dashboard. A pipeline that tracks blog posts by status. I keep adding stuff to it, because that’s what I do. And there aren’t any guardrails to keep me from doing that.

Or so I thought.

The bedtime prompt

Last night I hit a wall. The ingestion engine kept balking every time I captured a todo for myself. Things like “follow up on that last call with a note about the pizza place in NYC,” or “reach out to a friend in three weeks once he decides between a job and contracting.” It had no place to categorize todo items. Projects were covered. Blog posts were covered. The little things I just need to do had nowhere to live.

So I did what I do now. Before going to bed, I wrote out a significant prompt: research the successes and failures of todo tools, go through my archive and look at the three different todo systems I have built over the past year that have all gone fallow and understand why they stopped getting used, think hard about what I have that is working, was working, or never worked, compare all of that with the external research, and build me a plan for capturing todos. Then I went to bed.

Yes, I was literally commissioning “yet another task list”. The fourth in a year. Keep that in mind.

The Sunday thing

When I got up and reviewed the plan over coffee, it was good. Real research, honest analysis of why my systems die. Claude’s finding: every todo system dies at one of three points, capture friction, gardening burden, or missing pressure. Nothing nags, so it rots.

But one line stopped me. In describing the scaffolding I already have, the plan mentioned my daily note and “Sunday synthesis” as the pressure that keeps the system alive.

My first thought: what is that Sunday thing? I never looked at that.

Sit with that for a second. The pressure mechanism of my system was a report I did not know existed.

So I went and found it. And the tone and accuracy of the synthesis blew me away. Like, for real. Here is how it opened:

“What you did this week was spec and scaffold. What you did not do was write a post. Every committed post still sits in seed or drafting, and by your own note on each card, each one is a single editing pass from shipped.”

Some of those points are already handled, it was Thursday after all, and I shipped by just doing the work. But wow. And here is the key point: I never defined this report. Claude created the entire Sunday synthesis, the schedule, the format, the tone, from our original spec discussion about what I was trying to build. I asked for a filing system. It decided I also needed a mirror.

The accountability buddy

This made me think. The real value of this system is not the notes, or the second brain, or the task lists, or the pipeline that goes from idea to spec to review to build to test to deploy. Those are all table stakes now. Any of us can vibe code that stack in a weekend.

The value of the system is the accountability buddy. The thing that reads everything I actually did, compares it against everything I said I would do, and asks the uncomfortable question on Sunday whether I am ready for it or not. That is a pressure I need. And it only works if I look at it. If I never open the report, I will never change, and the whole beautiful machine is just scaffolding around work that is not happening.

I am wallowing in the last question it asked me, and I will leave it here without comment, because it deserves the last word:

“You spent the week building things to hold the work instead of making that pass. What is the pass waiting for that the scaffolding is standing in for?”

This Would Be So Much Better, but I Didn’t Have the Time

I’ve been building an office golf pool with Claude Code. It’s called Pin High Duel, and the mechanics are simple: take the tournament field, split the golfers into groups, and everybody picks one golfer from each group. The pool creator gets to pick how many groups are in the pool. Best combined finish wins.

The interesting engineering question is hiding in the middle of that sentence: how do you split a field of golfers, usually 156, into fair groups?

Claude Code was happily off building a model for it. Multiple modes, balancing logic, handling for every conceivable edge case. It worked. It was tested. It was more code than the problem deserved, and I could not have told you that yet, because I hadn’t really looked.

Then, as I was reviewing the PR, decades of pattern matching tapped me on the shoulder, and I typed one sentence: it should be field divided by picks with a max of 10 [golfers per group].

The reply came back instantly: “That’s a cleaner spec than what I built – and it actually simplifies the code into one formula instead of two modes.” Each group holds field divided by picks golfers, capped at 10, and the last group takes whatever’s left. One formula no matter how many groups your pool is set up for. The two modes and all of their edge cases just evaporated.

(The pool is real, by the way. You can play here: pinhighduel.com. Bring your bracket instincts, and until I get Stripe configured you can set up a pool and play for free!)

Recognizing simple is easy, finding it is hard

That exchange stuck with me, and not as a gotcha about AI. Claude did nothing wrong. It built exactly what I asked for, quickly and correctly. And notice what happened when I offered the simpler shape: it recognized it instantly, called it cleaner than its own work, and rewrote without a flinch. Recognizing simple is easy. Finding simple is the hard part.

Finding it is a skill that takes decades, and it did not come from coding. It is the skill of bringing the simple out of the complex, and it shows up everywhere: in math, in code, in org design, in test harnesses (in personal life!). The brute force version of each of those exists and mostly works. More terms, more branches, more boxes, more cases. The elegant version does the same job with less, and getting there is never the first draft.

It is not a common skill in people either, let’s be honest. But right now it looks like one of the telling differences between AI capability and human experience. The tools generate. Experience removes excess until the statue appears.

The shorter email

One of my mentors, Joe Austin, had a line I’ve used for years: “I would have written a shorter email, but I didn’t have the time.” (The joke is older than email, Pascal usually gets the credit, but Joe is the one who made it stick for me.)

I use it constantly because it names something true: short is not the lazy version, short is the expensive version. Getting a message, a design, or a function down to its core essential bits without losing the context takes thought, wisdom, experience, and time. The long version is what you produce on the way to understanding. The short version is what you produce after working through it.

Volume is now free

Here is why this matters more today than it did five years ago. With vibe coding and tools like Claude Code, GitHub Copilot, and Cursor, writing volumes of code has become incredibly easy. Volume is now free. Anyone can produce ten thousand working lines before lunch, and a lot of it will even be good.

Which means the scarce skill has flipped. It used to be hard to produce and easy to want less. Now it is easy to produce, and the rare, senior level move is the subtraction: the person who looks at the two modes and the balancing logic and says, quietly, it should be field divided by picks with a max of 10.

There is something amazing about the simplest solution that actually works. It is beautiful in a way that sprawling, technically correct code never is, closer to artwork than engineering. You know it when you see it, the same way Claude knew it when I typed it.

The tools will keep getting better, and honestly, I expect they will learn some of this. But today? Hold on to the people who can delete. They will write you a shorter function, if you give them the time.

The CIO, the CTO: Two Jobs That AI Rewrites

A short history of the two roles, and why the real story isn’t whether they merge. It’s how AI transforms both, pulling one toward the CFO and forcing the other to change its middle letter.

A couple of times a month, somebody asks me a version of the same question. With AI changing everything, should the CIO and the CTO become one job? Or should they split further apart? In an AI Native world, do you still need both roles?

It is the wrong question. It argues about boxes on a chart when the thing actually moving is the work. The more interesting question is how AI transforms each role.

Where the CIO actually came from

Nobody set out to invent the CIO. The role backed into existence.

In the 1950s through the 1970s, a company that owned a computer (yes kids some companies had “a computer”) had a Data Processing Manager. That person ran the mainframe, made sure payroll and inventory came out the other end, and kept the machine in the cold room humming. It was a deeply technical and operational job. It wasn’t strategic, it was closer to running the boiler room than running the business.

As the systems sprawled, the title grew up into Management Information Systems Director. Same core job, wider scope. You were not just keeping the machine alive; you were implementing business applications and occasionally handing management a report they could not have produced themselves.

The term “Chief Information Officer” showed up in 1981 in a book by William Synnott and William Gruber. Their idea was radical for the time: that information itself was a corporate resource, on par with capital and people, and it deserved a seat next to the CFO and the COO. The CIO was the person who managed information as an asset.

Then four decades of forcing functions did the rest. ERP. Y2K. The internet. Email. Security becoming existential. Cloud. Every one of those moved the CIO further from the cold room toward the boardroom. “What great looks like” for a CIO went from “the batch job finished on time” to “the systems are reliable and secure and cost what they should” to eventually, “technology is making the business measurably better.” The job kept getting more strategic, but its core never changed: the CIO is accountable for the machine running. Reliable, secure, governed, affordable. Run the business.

Where the CTO came from, and why it was different

The CTO arrived later and from a different direction.

It grew up in the 1990s, mostly inside technology and product companies, and it started as the chief engineer or chief architect. The person who owned the technology vision and the R&D bet. In a software or tech hardware company, the CTO owned the thing you sold. They lived next to engineering and product, and their job was to be right about where technology was going.

When the CTO title migrated into ordinary enterprises (banks, retailers, manufacturers), it kept that outward, forward lean. In a bank, the CIO keeps the core banking systems stable and secure. The CTO is the one pushing the mobile app, the new platform, the AI bet. One is pointed inward at operations and employees. The other is pointed outward at products and customers.

That is the cleanest way to differentiate the two: the CIO runs the business, the CTO changes the business. Reliability versus reinvention. Operate versus explore. The drawer where the tools are organized, versus the workbench where the new thing gets built.

The reason these were two seats was never the titles; it was because the two motions pull against each other. One optimizes for “nothing breaks.” The other optimizes for “we break things to drive change.” Put both functions in one place with one budget and one set of incentives, and someone always loses. Usually invention loses, because the pager goes off for outages, not for missed opportunities.

What happens next

I’ve thought about this a lot; there are many ways to navigate what’s coming next, but the most effective model is:

The CIO focuses on run – operations at scale is critical, and that has to be their success metric. With almost all infrastructure available through cloud and AI providers, the CIO’s best partner is the CFO.
The CTO changes their “T” – they must understand technology, but their role is to lead the Transformation to AI Native. The CTO has to pivot, their new best partner is the CPO, the Chief People Officer. This isn’t about choosing a technology stack anymore, this is about your people transforming.
Everyone has to embrace the change to AI Native – you either lead the change or it happens to you.

Start with the CIO, because the easy mistake is to read “shrinking footprint” as “shrinking importance.” Cloud did not make the CIO less important, it made the role more manageable. Those are different words. The surface area shrank, but importance held. When the machine is something you rent rather than something you build, the hard questions become consumption and cost: what are we paying, what are we actually using, are the vendors earning what we’re paying them. That is why the CIO’s center of gravity drifts toward the CFO. Run becomes a financial discipline.

The CTO is the opposite shape. It was always the forward-looking seat, and here is the part we never said out loud: a lot of what made that work was that change used to be slow. You could see a trend coming, and you had the time to aim at it. The great CTOs aimed a little faster, and made high value bets. You could be early, be a little wrong, and reposition before it cost you. Vision paid off because the future arrived at a walking pace. The CTO got to be the person who saw it first and had time to act.

That slack is gone. AI is not a new tool on the bench, it is a whole new workshop. It is an accelerant on the rate of change itself, and the rate is compounding. The future is no longer arriving at a walking pace; it is arriving faster every quarter, soon to be every month, then every week. In that world the value of the CTO stops being “pick the right technology” and becomes “build a company that can absorb a new future on repeat.” Vision stops being a telescope you look through occasionally and becomes flight controls you never take your hands off.

The best CTO today needs to see a little further down the road than everyone else and get the company ready for change. That is the whole job. Nobody sees past the event horizon. Anyone selling you a five-year AI roadmap right now is selling you snake oil, because we are wildly early. My first cell phone was a handset bolted to the console of my Chevy S-10 with a cord running into the dash, and I was sure I had arrived. We are at that phone-in-the-truck stage with AI, and the road past the next curve does not exist yet. So the job is not prophecy, it is keeping a fast-moving, low-visibility vehicle pointed in the right direction, and building an organization that can take the next turn without spinning out.

The CTO has to raise their view and widen their aperture. They have to walk fully out of the research lab they were born in. The job is no longer to own the technology, it is to own what the technology does to the company: not the resident expert on the new tech, but the person accountable for the whole organization metabolizing a new future on repeat, faster than it is comfortable doing it.

A different job needs a different partner. This is the tell that the role has changed, not just relabeled. The old CTO was wired into the technical core. In the enterprise that meant standing shoulder to shoulder with the CIO and engineering, vision next to operations and product. The CTO’s closest alliance was with other technologists.

Becoming AI Native is not a technology problem; it is an organizational one. The new alignment is CTO and CPO, vision next to organizational design. One side reads the road and decides where the company has to go. The other side rewires the org so it can get there, reshaping teams, retraining people, changing how the work is divided so the whole company can accelerate with AI. Org charts, span of control, promotions, incentives, budgets – it all has to change. You have to build a company that can absorb change at pace, and you build it through people. A transformation seat that stays glued to the CIO and the engineering org is solving the old problem, stuck in the past. The one that pairs with the CPO is solving the new one.

How both roles transform

So, back to the question: Merge or Split? Neither. That was always the wrong frame, because both options try to bolt AI onto the org you already have, keeping the boxes on the chart and adding “…with AI” to each one. AI is an “empty the cup” moment.

The CIO does not disappear, it tightens. Run becomes a sharper, smaller, more financial discipline that holds the guardrails and watches the meters, shoulder to shoulder with the CFO. The CTO does not disappear, but thrives when they walk out of the lab, partner with the CPO, and transform how the whole company works.

The companies that win the next decade will not be the ones that picked the cleverest org chart or the coolest technology today. They will be the ones that understood, early, that AI Native is not a tool you adopt but a change you lead. You either drive the change, or it happens to you.

Seven Clicks a Day, Forever

I built a three-skill pipeline so I’d never have to “Download transcript” again. The pipeline isn’t the point.

I record a meeting with myself every day.

It’s not a meeting. It’s me, at my desk (or in the car, or on a run), talking out loud to Teams for fifteen or twenty minutes about what I’m trying to do that day: the threads I’m pulling on, the half-finished decisions from yesterday, the things I’m worried about, the projects I need to start or finish, the things I’m excited about. I hit record, I talk, I hang up.

Then Teams transcribes it. And that transcript is gold. Because it isn’t notes I had to type. It’s me, thinking out loud at the speed of speech, in my own voice, with all the messy connective tissue that I never bother to write down. It is the single richest piece of context I can give to my agent for the rest of the day.

But to get it into the agent’s hands, I had to do this every time:

Open Teams.
Find the meeting in the chat.
Click into the recap.
Open the transcript pane.
Click the three dots, click Download, pick .docx.
Convert to txt so the agent can really consume it.
Move the file from Downloads into the folder my agent watches.

Seven clicks. Every day. Forever.

That’s the kind of friction that kills a workflow before it has a chance to compound. I knew it. I felt it every morning. And every day I did those clicks anyway, because the payoff was worth it. Many days, more than once.

I’ve done this for months, and couldn’t build a way around it, until now.

The real point isn’t the meeting

I want to be honest about what this project actually was, because the surface description (“I automated Teams transcript downloads”) sells it short.

The point is not that downloading a Teams transcript is hard. It isn’t. It takes less than a minute.

The point is that a manual task done every single day, forever, is the single most expensive thing you can put in your workflow. Not because of the minute it takes. Because of the decision cost: the tiny moment every time where I have to remember to do it, choose to do it, and then mentally context-switch out of “I’m about to work” into “I’m doing data plumbing.” That decision cost is what kills the workflow. The transcript stops happening. The agent stops getting the context. The agent’s outputs get worse. I notice. I get frustrated.

The fix wasn’t a better agent. The fix was making the input arrive without me.

The constraint that shaped everything

The clean version of this is one Graph API call. GET /me/onlineMeetings/{id}/transcripts/{id}/content returns the .docx. It’s a one-liner.

It’s also blocked in my tenant. Admin consent on OnlineMeetingTranscript.Read.All is not happening. Nobody is going to grant that permission to one rando in a 200,000-person tenant. The answer was no, and the answer is going to stay no, and that’s fine; I’m not building a product, I’m building a workflow for me.

So the entire design had to assume that the only reliable way to get a transcript is to drive the Teams web UI like a human would. Playwright. Click the buttons. Wait for the download. Move the file.

Once you accept that constraint, the shape of the solution starts to come into focus.

Three skills, one pipeline

I broke the work into three pieces, each doing one thing, each independently useful.

Stage 1: /transcript-watcher polls my OneDrive Recordings folder every thirty minutes. Teams puts a new MP4 there every time a recorded meeting ends. When the watcher sees a new file whose name matches one of my watched series prefixes, it knows there’s a transcript to go get. It pings me in Teams (“I see a new recording for X, going to grab the transcript”) and invokes the next skill. The expensive thing (Playwright) only runs when there’s actual work.

Stage 2: /meeting-transcript is the Playwright driver. It opens Teams in a real browser, finds the meeting in the chat, opens the transcript pane, clicks Download, waits for the .docx, and saves it to a watched folder with a sensible filename. This is also the skill I can invoke directly when I want a transcript for a meeting that happened weeks ago.

Stage 3: /doc-watcher watches the folder. When a new .docx lands, it converts it to plain-text Markdown using Word COM (headless), pings me in Teams that it’s ready, and the original .docx never gets touched.

End to end: about thirty minutes typical, an hour worst case (the recording has to finish processing in OneDrive before stage 1 can see it). Zero clicks from me. If I want it right now (I usually do), I kick it off manually. Soup to nuts in three minutes.

The Markdown file lands in the same folder my agent reads at the start of every conversation. The agent sees this as ambient context. It knows what I was worried about. It knows what threads I’m pulling on. It knows what I’m trying to do that day. I didn’t have to tell it. I just had to talk.

The gotcha that confused me

One detail almost broke the whole thing.

The Recap picker in Teams shows the scheduled meeting time, not the actual recording start time. So my standing one-on-one with myself is scheduled at 18:45, but I actually hit record at 12:20, and the file the pipeline produced was named with 18:45. I do this more than once a day, so multiple files collided because they were all “scheduled at 18:45.”

The fix was to stop trusting the Recap picker and read the recording start time out of the chat thread instead. Three regex cases (English UI, localized variants, edge formatting) cover everything I’ve seen. The skill warns loudly if it falls back to the picker’s value, so I’ll notice if a fourth case shows up.

A workflow you can’t trust is a workflow you’ll abandon. Naming has to be right or none of the rest of it matters.

What this actually unlocked

The transcripts arrive. The agent reads them. I haven’t clicked “Download transcript” once.

What I didn’t expect was the second-order effect. Because the friction went to zero, I started recording more things: short voice memos between meetings, a five-minute postmortem after a hard call, a quick “here’s where I left this” before I close the laptop. All of it ends up as Markdown in the same folder. All of it becomes context.

The pipeline removed seven clicks. Removing those clicks made me record three times as often. The agent’s context window got an order of magnitude richer. Jevons’ paradox in action.

That’s the trade I want to keep making: find the daily friction, automate it down to zero, then watch the behavior on the other side of the friction explode.

The three skills are live

All three are published on SkillWorks if you want to lift them. They’re Clawpilot skills: install them with /install, configure your paths, and you’re running. They should work fine with GitHub Copilot, Copilot CoWork, or other systems with minor modifications. Ask your agent to adjust them.

Teams Transcript Pipeline: the full write-up (the why, the design, the dead ends)
/transcript-watcher: polls OneDrive for new recordings
/meeting-transcript: drives Playwright to pull the .docx
/doc-watcher: converts .docx to plain Markdown and pings you in Teams

Each one is independently useful. The doc-watcher in particular has nothing to do with Teams. Point it at any folder of Word documents and you’ve got a feed of plain-text copies that your agent can use.

Your turn

What’s your seven-clicks-a-day workflow? The one you’ve been doing forever because the payoff is worth it, but the decision cost is starting to fray?

Drop it in the comments. Half the time I see somebody else’s, I realize I have the same one and didn’t notice.

More of what I write lives at signalnotsentiment.com. Lessons from doing, not theorizing.

Phone in the Truck

Why I think we’re nowhere near as far along on the AI curve as it feels.

I’m old enough to remember the time before cell phones.

I had a phone on my desk at work. I had a phone at home, the one with the long curly cord, attached to an answering machine that I rewound by pressing a tiny tape down with my thumb. That was the communication stack. That was it. Different numbers, different functions.

Then I got my first cell phone. And it wasn’t really a phone, not the way you’re picturing it. It was a handset bolted to the console of my Chevy S-10, right next to the gear shift. A cord ran from the back of it down into the dash for power. The buttons were on the back of the handset. You could pick it up and put it to your ear like a regular phone, or you could leave it cradled and hit speaker.

I thought I had arrived.

For the first time in my life, the dead hours of a commute became productive hours. Driving to a meeting, driving to a sporting event, driving home late, I could communicate. I told everyone I knew that this thing had changed my productivity forever.

It had. It just wasn’t what I thought it was.

Every stage looked like the peak from the inside

Then Nokia happened. The flip phone. The bar of soap phone. Auto-answer with a headset jack, which felt like science fiction, because now I didn’t even have to reach into my pocket. If it rang, I started talking. Productivity unlocked. Again.

Then keyboards. BlackBerry. Windows Mobile. Email in my hand. I remember thinking, this is it, this is the force multiplier. What more could you possibly need?

Then the iPhone. Apps. Then data, slow and unreliable at first, but a web browser in your pocket, which was a concept that had not existed before. Then real apps. Then Bluetooth, which we all made fun of until every single one of us was wearing it. Then video calls. Then maps that knew where you were. Then a bank in your pocket. Then a camera better than the one in my closet.

At every single one of those stops, I thought we had arrived.

I was wrong every single time.

The phone in my truck and the phone in my pocket today are not the same product. They are not the same category. They are barely the same species. And the version of me sitting in that truck in 1992 could not have described to you what the device in my pocket is today, because the words for it did not yet exist.

Now look at AI

I have a fleet of agents working for me right now.

One of them triages my inbox before I’m awake. One of them rewrites my drafts. One of them sits on my calendar and resolves conflicts before I see them, then sends me a morning report telling me what it moved and why. One of them builds dashboards on demand. One of them runs a weekly report on how many tokens I burned, how many artifacts got produced, and a rough estimate of how many hundreds of thousands of dollars of human effort would have been required to do all of that two years ago.

I am, by any reasonable measure, more productive than I have ever been.

And every time I demo a piece of this to someone, the reaction is the same. This is incredible. This is the future. We must be so close to the peak.

I keep wanting to agree with them. I have lived inside the productivity gain. I know what it feels like.

But I’ve been through this movie before.

We’re in the S-10

We are not at the iPhone moment of AI. We are not at the BlackBerry moment of AI. I don’t think we’re at the Nokia moment of AI.

I think we’re at the phone in the truck.

I think the version of AI my kids are going to use in a decade is going to be as unrecognizable to us, sitting here in 2026, as a modern smartphone would have been to me sitting in my truck in 1992. The words for it don’t exist yet. The form factor for it doesn’t exist yet. The social patterns for it don’t exist yet. We don’t even have the right complaints yet, and complaints are usually a leading indicator that a category is mature.

The exponential nature of this curve fools us. It feels like we’re moving so fast we must be near the end, when in reality the speed is the tell that we’re near the beginning. Things move fastest when they have the most room left to run.

The fact that the pace has compressed does not invalidate the pattern. It just means we’re going to see the next several stages inside a single career instead of across three of them.

So when somebody asks me where we are on the AI curve, I have a real answer now.

I’m in the truck. The cord goes into the dash. The handset is next to the gear shift. And I am absolutely certain I have arrived, in exactly the way I was certain the last four times.

Your turn

Where do you think we are on the AI curve? Phone in the truck? Nokia flip? BlackBerry? Early iPhone? Something later?

Drop your honest answer in the comments. Bonus points if you can name the feature you’re using today that will look as quaint in ten years as a handset bolted to a dashboard looks now.

Lessons from doing, not theorizing.