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.