The Technology Executive

Someone shared another one of those enterprise architect versus solution architect infographics in my feed a few weeks ago. Clean two-column layout. EA on the left, SA on the right, bullet points about scope and depth and horizons. The usual. These charts always leave out the person who, in my experience, is the one actually making a large program work. You will not find this role on most of them. In the SAP and Workday worlds, we sometimes call them functional architects. Sometimes functional leads. Sometimes a senior consultant with a lead title and no architect in it at all. The label changes. The job does not. The EA vs SA Map That Everyone Draws Before I argue about the gap, it is worth saying what the usual chart gets right. The enterprise architect owns the long view. Capability models, standards, the portfolio of applications a company is going to run three years from now and the ones it is going to turn off. TOGAF , the usual reference frame here, puts them in a str...

I manage my business with a small fleet of AI agents now, and the hardest problem I've hit is not getting them to reason well. It's getting them to remember the right things, for the right amount of time, and to forget the rest. I learned this the slow way, by building my own memory system twice. I Built This Twice, and the First Version Failed for a Boring Reason The first version was what I'd now call an agent-brain: a folder of notes the agents could read and write, organized by project (my take on the Karpathy LLM Wiki). It worked for about a month. Then it started contradicting itself. A decision I'd reversed in August was still sitting next to the reversal in September, and the agent had no way to know which one was current. Nothing was wrong with the notes. What was missing was a layer above them that tracked state: what's an action in progress, what's a decision that's final, what's a fact that just needs distilling later. That gap is why I ...

Teams across the market are smaller than they were two years ago and getting more done. Almost all of them have the same hole: nobody junior. That gap didn't start with AI. Long before generative AI, a lot of companies were already avoiding junior hires, because junior people are difficult and expensive to develop : years of mentoring, tolerance for mistakes, a willingness to pay someone to learn on the job. The youth unemployment numbers have been ugly for a while because of it; recent college graduates were already unemployed at roughly 5.6%, well above the 4.2% national rate , before you even get to AI. AI isn't creating that problem. It's making it worse, because the junior work, drafting the first pass, pulling the data, writing the routine ticket response, is exactly the work AI now does before a human touches it. The debate about AI and jobs keeps getting framed as one question: does AI take jobs, yes or no. That framing is already wrong, and the data coming out thi...

Open your feed this week and you'll find two competing panics: Today, its AI is about to take everyone's job and previously it was that companies suddenly need everyone back in the office. We had that second argument for three straight years before AI showed up. I want to set the headlines aside and look at this the way an economist would: what is a salary actually buying, and does AI change the answer. That's a more useful question than either panic, and it's the one that actually determines what happens to anyone's pay. You're Paying for Time, Outcomes, or Units. Pick One. Hourly pay is honest about what it is: you're buying a block of a person's time at a given skill level. There's no ambiguity to resolve when a tool makes that person faster. Fewer hours, less pay, full stop, assuming the work still gets done to standard. A salary is a different contract, whether anyone wrote it down this way or not. It's closer to fixed-price consultin...

Nobody Has Priced This Yet In my day-to-day, I speak to leaders at lots of consulting firms and we keep ending up in the same conversation: what do we do about AI and pricing? The problem is not that there is no answer. The problem is that there are too many, and every one of them assumes something that may not be true: that the consulting firm can actually manage the cost of AI in the first place. That is a big assumption for an industry where, by micro-segment, plenty of firms are a few bad months from closing their doors. Layer on the fact that clients want projects faster and cheaper while firms are trying to protect or grow margin, and you have a genuine standoff. AI does not resolve that tension. It just gives both sides a new variable to fight over. The Fee Nobody Wants to Admit Is a Rate Cut The first instinct I see is a technology fee, a separate line item for the AI tooling. I dislike it the most. It has the same feel as a baggage fee or a credit card surcharge: I am b...

What Soren Kaplan Gets Right, and Where I'd Push Back I read Soren Kaplan's recent Inc. column arguing that consulting disruption has finally arrived, that once AI can generate a strategic plan or synthesize market trends in seconds, the rules of what clients pay for change completely. He's right about the direction. After nearly three decades in this industry, and the last few years watching AI move through dozens of engagements alongside consulting partners of every size, I'd push back on the timeline, and on what's actually being disrupted. Buyer Expectations vs. Consulting Realities Procurement has been told, by vendors, by analysts, by their own boards, that AI should be cutting consulting costs dramatically by now. Consulting firms have been told to adopt AI or get disrupted. The savings clients budgeted for still haven't materialized at the scale they were promised, and that's the gap: procurement asking where the savings are, delivery explainin...

I get some version of this question at least once a quarter, usually from a CIO who just sat through a brutal renewal negotiation or is frustrated by the cost of an upgrade: "Was moving to the cloud a mistake?" The honest answer is that most of the people asking it aren't actually asking about the cloud. They're asking about something else entirely, and until they separate the two, they're going to keep making the same expensive decision over and over. The Cloud Is a Landlord, Not a Product Let's start with what "moving to the cloud" actually means, because the term has been stretched past usefulness. At its core, it's moving your workloads into data centers that aren't yours, typically a hyperscaler's. You're renting infrastructure: compute, storage, networking, physical security, and a deeper bench of specialized expertise than almost any single enterprise IT shop can staff internally. That's a legitimate, often excellent, ...