96% of Your Team Uses AI. Almost None of Them Use It Well.

The headline is the one everyone will repost: 96% of IT pros now use AI. Here is the number nobody is talking about: only 49% use it frequently. That gap, and the 10-hour weekly AI tax hiding in your capacity plan, is your real problem.

Read the article →
Your team isn't using AI. AI is using your team.

A Wharton study should stop every technical leader cold. When AI gives a wrong answer confidently, people accept it 60% of the time. The accuracy gap between a right AI and a wrong AI was 44 percentage points. That's not augmentation. That's cognitive surrender.

Read the article →
The CTO Who Knows Too Much

Experience is supposed to be the asset. At a certain point, it becomes the liability. Here's how to tell which one you're carrying.

Read the article →
Your Engineering Team Is Moving Fast in the Wrong Direction

Velocity is not progress. It is often waste at scale. A fast team pointed at the wrong problems isn't just unproductive – it's a liability. Here is where the trap starts, and what fixing it actually requires.

Read the article →
The Moment Nobody Talks About

Product hands dev a requirements doc. Dev builds to spec. Product says "that's not what we meant." That moment – small, frequent, almost invisible – is the central problem in most software companies.

Read the article →
15 July 2026 LinkedIn
The thing nobody tells you about the first 90 days is that you are also being evaluated on how you handle being wrong. You will make a call in month one that turns out to be the wrong call. It is inevitable. You are working with...
View on LinkedIn →
13 July 2026 LinkedIn
By day 60, you should know three things. Where the actual technical risk is. Not the risk that shows up in architecture diagrams or sprint reviews. The real...
View on LinkedIn →
10 July 2026 LinkedIn
In the first 90 days, the engineering team is watching you more carefully than you are watching them. They have seen CTOs come in before. They have watched the ones who arrived with all the answers. They have watched the...
View on LinkedIn →
8 July 2026 LinkedIn
The first 90 days as a CTO is not about proving yourself. It is about understanding what is actually true. Every company I have walked into had a story they told themselves...
View on LinkedIn →
6 July 2026 LinkedIn
By the end of week two, I want to know three things. Where is the pain? Not the pain leadership describes in the interview process. The pain the engineering team lives with...
View on LinkedIn →
3 July 2026 LinkedIn
By day thirty you should know three things: what the team is proud of, what they're afraid of, and what they've stopped trying to change. That last one is the most important. The things a team has stopped trying to change are the load-bearing problems....
View on LinkedIn →
1 July 2026 LinkedIn
The first thing I do when I step into a new CTO role is not look at the code. I talk to people. Every engineering lead. Every product manager. The head of sales. The head of customer success. The...
View on LinkedIn →
29 June 2026 LinkedIn
The CTO who says yes to everything is not an asset. They're a liability. Every engineering team has more things it could build than it has capacity to build well. The...
View on LinkedIn →
26 June 2026 LinkedIn
Boards don't want a technology update. They want confidence. I've sat through a lot of board presentations where the CTO spent 20 minutes explaining the...
View on LinkedIn →
24 June 2026 LinkedIn
There is a version of the CTO role that is essentially a senior engineer with a title. They go deep on architecture. They review pull requests. They have strong opinions about frameworks. They are...
View on LinkedIn →
22 June 2026 LinkedIn
The org chart is a product decision. How you structure an engineering team determines what that team can build, how fast they can build it, and what kinds...
View on LinkedIn →
19 June 2026 LinkedIn
The roadmap is not a technical document. I've watched engineering teams spend weeks building beautiful roadmaps full of epics and milestones and dependency...
View on LinkedIn →
17 June 2026 LinkedIn
Most CTOs I've met can tell you exactly how their system is architected. Ask them what the company's gross margin target is and you get a blank stare. That's the problem. A CTO who only...
View on LinkedIn →
15 June 2026 LinkedIn
The question I get most often from founders who've just hired me: "How long will it take to fix the engineering team?" My answer is always the same: that depends on one thing. Not the tech debt. Not the architecture. Not the size of the team or the complexity of the product. It depends on...
View on LinkedIn →
12 June 2026 LinkedIn
Here's what I tell every engineering team I walk into: The AI tool is not your teammate. It's a very fast, very confident intern who has read everything and understood almost none of it. That's not an...
View on LinkedIn →
10 June 2026 LinkedIn
The codebase is a fossil record. Every commit tells you something about the conditions under which it was written. A commit with a thoughtful message,...
View on LinkedIn →
9 June 2026 LinkedIn
The AI race isn't going to be won by the team that generates the most code. It's going to be won by the team that can actually govern what it built. Anyone can spin up agents. The hard part is...
View on LinkedIn →
8 June 2026 LinkedIn
An interim CTO's job isn't to be the smartest engineer in the room. It's to be the person who asks the question everyone else stopped asking. In an AI-assisted org, that question is...
View on LinkedIn →
5 June 2026 LinkedIn
Three signals that tell me cognitive surrender has taken hold in an engineering org. I look for these in the first two weeks. They're never hard to find. 1. PRs approved in under two minutes. Not because...
View on LinkedIn →
3 June 2026 LinkedIn
The most dangerous six words in a post-AI engineering org: "It looked fine in code review." Here's what that sentence actually means: The code was generated by an AI. It was syntactically clean. It passed the linter. The reviewer scanned it, felt no friction, and approved it. Nobody...
View on LinkedIn →
1 June 2026 LinkedIn
I can tell how broken a team is by how they talk about their AI tools. Healthy team: "We use Copilot for boilerplate and first drafts. We review everything. It's saved us maybe 20% on the...
View on LinkedIn →
29 May 2026 LinkedIn
**The autopilot problem in engineering orgs isn't the AI. It's the conditions that make autopilot feel rational.** Think about what you're asking an engineer to do: - Ship...
View on LinkedIn →
27 May 2026 LinkedIn
**Here's the interview question I use to find engineers who haven't surrendered.** Not a coding challenge. Not a system design question. One question: *"Tell me about the last time you overrode something an AI tool suggested....
View on LinkedIn →
25 May 2026 LinkedIn
**The first thing I do when I step into a broken engineering org is look for the commits nobody questioned.** Not the bugs. Not the outages. The commits. Specifically: the ones where an AI tool generated the solution, the engineer approved it...
View on LinkedIn →
22 May 2026 LinkedIn
This is what cognitive surrender looks like inside an engineering org. A developer opens Copilot. Gets a suggestion. It compiles. It passes the linter. It looks right. They commit it. Did...
View on LinkedIn →
20 May 2026 LinkedIn
"We tried incentives. We tried feedback. Cognitive surrender persisted anyway." That's the finding from Study 3 of the Wharton cognitive...
View on LinkedIn →
18 May 2026 LinkedIn
Your team isn't using AI. AI is using your team. A Wharton study gave participants an AI assistant that was either correct or deliberately...
View on LinkedIn →
18 May 2026 LinkedIn
The engineer your org is rewarding most may be your biggest AI risk. High AI trust. Fast mover. Ships constantly. Gets praised in stand-up. Also: the profile most likely to surrender…
View on LinkedIn →
16 May 2026 LinkedIn
The most dangerous moment in most software companies is the handoff. Not the one between product and engineering – though that one is bad too. The one between sales and delivery. A deal…
View on LinkedIn →
15 May 2026 LinkedIn
Cognitive surrender is why your AI-assisted team is getting slower, not faster. Not slower at shipping. Slower at thinking. A Wharton study just named the phenomenon: when AI gives a confident,…
View on LinkedIn →
14 May 2026 LinkedIn
There's a term product people use in private that leadership rarely hears: Feature factory. It's what happens when a team is optimized for output: shipping features, closing tickets, hitting sprint goals –…
View on LinkedIn →
9 May 2026 LinkedIn
Net revenue retention is the most honest metric in your business. It tells you whether customers who bought from you last year think you were worth keeping this year. And here is the thing about NRR: it cannot be spun. Either they renewed and expanded, or they didn't.
View on LinkedIn →
7 May 2026 LinkedIn
Technical debt is not a technical problem. It is a strategy tax. Every shortcut taken to ship faster is a bill sent to the future. The future pays it in slower delivery, harder debugging, longer onboarding, and a codebase that gets increasingly expensive to change. Debt sprints pay the interest. They never touch the principal.
View on LinkedIn →
5 May 2026 LinkedIn
The annual plan is a bet made in January about what the market will want in December. That bet is almost always wrong by March. And yet most companies spend the rest of the year executing the January plan anyway.
View on LinkedIn →
2 May 2026 LinkedIn
Your sales rep knows something your product team doesn’t. They know exactly why deals are stalling. If you want that information, you have to build a system that surfaces it before the deal dies.
View on LinkedIn →
30 April 2026 LinkedIn
The most expensive words in a software company: “It’s almost done.” Almost done means it’s in the sprint. It means engineers are on it. It means leadership is waiting on it. Almost done has been absorbing capacity and blocking decisions for weeks.
View on LinkedIn →
28 April 2026 LinkedIn
You can tell a company isn’t aligned by watching one meeting. Not the all-hands. Not the QBR. Watch the roadmap prioritization meeting. Real alignment means someone in the room has the authority and the information to make a decision that sticks.
View on LinkedIn →
24 April 2026 LinkedIn
Nobody wants to be the one who says the project is behind. So nobody does. The answer is not “speak up more.” The answer is a system where surfacing problems early is rewarded, not penalized.
View on LinkedIn →
22 April 2026 LinkedIn
Most founders do not know they have an engineering problem until they have a sales problem. Sales is where the system tells the truth. Start there, then trace it back.
View on LinkedIn →
20 April 2026 LinkedIn
The cheapest engineering problem to fix is the one you catch before it gets built. This is obvious. Everyone agrees with it. Almost nobody has a system that actually does it.
View on LinkedIn →
17 April 2026 LinkedIn
Your engineering team is not slow. They are slow relative to the expectations that were set without them in the room. There is a difference.
View on LinkedIn →
15 April 2026 LinkedIn
The sprint review went fine. Everyone presented their work. Stakeholders nodded. A few things got pushed to next sprint. The demo worked this time. Nothing changed.
View on LinkedIn →
13 April 2026 LinkedIn
Technical debt is not an engineering problem. I know it feels like an engineering problem. The engineers are the ones who built it. But the decisions that created it happened in product and leadership.
View on LinkedIn →
10 April 2026 LinkedIn
Sales closed a deal on a feature that does not exist yet. Sometimes it is reckless. Sometimes it is exactly right. The difference is whether engineering knew about it before it was promised.
View on LinkedIn →
6 April 2026 LinkedIn
The roadmap is not the problem. I know it feels like the roadmap is the problem. It is always changing. It is never right. Engineering resents it. Sales ignores it.
View on LinkedIn →
3 April 2026 LinkedIn
There’s a term I use for what happens when leadership says they want to change how the company works , but never changes how they work. Feral teams. When an execution transformation fails, we blame the teams. We rarely blame the executives who built the system the teams are trapped inside.
View on LinkedIn →
1 April 2026 LinkedIn
“We need better communication between product and engineering.” I have heard this at almost every company I have worked with. It is almost never the real problem. Communication is a symptom. Structure is the cure.
View on LinkedIn →
Reading about the problem
is a start. Fixing it is the point.

If something here resonated – it's probably because you're living it. One conversation is usually enough to figure out where the system is breaking down.