I tried to quit sugar many times. Willpower. Cutting back. Making rules. Nothing worked. I’d last a few days, maybe a week, then find myself back where I started.

Then a mentor said something to me — I don’t remember her exact words. Something simple. Maybe just: “Why don’t you give up sugar?” But something in that moment shifted. Not my willpower. Not my strategy. My identity.

That was many years ago. I haven’t had refined sugar since.

Once I became someone who doesn’t eat sugar, checking labels and passing on the cookie just happened. I wasn’t fighting myself anymore. The doing flowed from the being.

What if you aren’t getting what you want — not because of your skill or your effort — but because you’re approaching it from the wrong direction?

Most people work from a simple assumption: if I have the right things — talent, connections, experience, money — I can do what I want, and eventually be who I want to become. Have → Do → Be.

A salesperson thinks: if I had a nicer car, I’d do more sales calls, and I’d be more successful. An executive thinks: once I have the right team in place, I’ll do the hard work, and the company will be what I want it to be.

This feels logical. It’s also backwards. And when you believe it, you give up without realizing it — because you’ll never have enough to start.

The sequence runs the other way. You start with BE — your identity, how you see yourself, who you’re committed to becoming. That identity drives DO — the actions that flow naturally from who you are. And consistent action produces HAVE — the outcomes, the results, the life.

Be → Do → Have. Identity first. Always.

If you take on the identity of a dictator, you start acting like one — and you’ll get the results a dictator gets. If you take on the identity of a collaborative leader, you seek input, build buy-in, and get different results. Neither is inherently right. Sometimes you need to be a dictator. If the building is on fire, you don’t ask for consensus on which exit to take. But you’re choosing the identity deliberately — not defaulting to it.

In my work at ITX, when I’m pushing ideas that are more doing than being, I feel the difference. The effort is higher. The results are thinner. When I connect to a clear way of being first — something like I am a leader who brings out the best in people to deliver ever-increasing value to our clients — the doing gets easier and the results get better. Less force. More flow.

The declaration matters. Naming your identity out loud — to yourself, to your team — changes how you act. Not because you’re performing it, but because identity shapes perception. You start noticing things you couldn’t see before. Options appear that weren’t visible when you were grinding at the level of tasks and goals.

So here’s the question worth sitting with: where in your life are you working at the level of doing or having — and wondering why nothing is changing?

What identity would make the actions you want to take feel natural instead of forced? Who do you need to be — so that the doing just follows?

You don’t need more willpower. You need a different starting point.

AI can write 1,000 lines of code in minutes. Congratulations. You’ve just moved the bottleneck.

For thirty years, the central constraint in software development was writing code. We spent decades trying to address it — frameworks, higher-level languages, agile processes, continuous deployment. We got better at it. We never removed it.

AI just removed it.

And if you keep trying to build software the same way, you’re going to end up with a very fast, very expensive process that produces the wrong things. The Theory of Constraints is clear: remove a bottleneck, and it moves somewhere else. The question is where it moved — and whether your organization is set up to deal with it.

The Old Process Was Designed Around the Wrong Problem

At its simplest, software development follows this arc: strategy → roadmap → backlog → iterative delivery. The bottleneck was always in that last step — writing the code. So we optimized everything around it.

AI doesn’t just write code quickly. It writes epics, user stories, test cases, and strategy documents quickly. It changes the entire cost structure of building software. If you can produce a working prototype in a few hours, the cost of throwing it out and trying something different is almost nothing.

That changes everything upstream.

There’s an old story about a crew working in a jungle. They’re chopping trees, clearing land, optimizing their tools to go faster. Then someone climbs a tree, looks out, and yells — wrong jungle.

Two New Constraints

With AI, two new bottlenecks emerge. Both are harder to solve than writing code.

1. Decision Making

The question is no longer “can we build it.” It’s “should we build it — and does it connect to what the business actually needs?”

Years ago, approximately 90% of feature requests Microsoft received for Word were already in the product. Users didn’t know. That caused Microsoft to rethink the entire UI and create the ribbon. When you can produce features quickly, the natural outcome is feature bloat, user confusion, and a maintenance nightmare. The constraint becomes strategic decision making.

And here’s the problem: our current processes were designed to make those decisions at the speed of humans writing code. Slowly. As the constraint shifts, those decision loops need to speed up dramatically. Otherwise you end up with a lot of resources building things without clear direction on what to build.

There’s good news too. With the cost of working prototypes dropping dramatically, we can now vet ideas with actual software in front of real users — not focus groups, not surveys. Real feedback on real things. But only if your decision-making process is fast enough to use it.

2. Governance

The second constraint is governance. And it’s more complex than it first appears.

When AI can write 1,000 lines of code in minutes, how do you verify it’s right? How do you verify it’s safe? How do you verify it’s actually aligned to what the business needs?

The obvious answer is “have humans review it.” But humans can’t review at AI speed. And having AI write its own test cases doesn’t solve it either — that’s just asking the same system to grade its own homework.

Governance at AI speed has to be a system, not a person.

And that system has more layers than most people think about. Automated scanning. AI-vs-AI validation using multiple models to check each other’s output. Architectural design that limits how much damage a bad piece of code can do. Identity and authorization — who approved this, at what level, with what credentials. Compliance — AI doesn’t inherently know your HIPAA obligations or your SOC2 requirements, that knowledge has to be built in explicitly. Data governance — what data is the AI touching, or potentially leaking.

And yes, there’s still human review. But applied strategically, not uniformly.

Adding copy to a marketing page? Automated scans, quick approval, move on. Changing the algorithm that calculates a financial metric driving millions of dollars in decisions? Human eyes, compliance review, full authorization trail.

Not everything needs the same checks. But everything needs some checks. And your highest-risk changes need more rigor than most teams currently apply even to their most careful work.

A New Development Process

The software process needs to fundamentally change to address these new constraints. Not incrementally — fundamentally.

That means rapid prototyping paired with sophisticated deployment processes and advanced governance. Build working prototypes fast to learn what to build. Once you’ve found something with strong user signals, shift gears — rigorous governance, security reviews, performance testing. Build once you know what matters, not the other way around.

How to Adapt

No one has fully figured this out yet. But a few things are clear.

Decision making and feedback loops need to dramatically improve. You need more sophisticated ways to understand what users actually need — not what they say they need in a survey, but what real behavior tells you. You need clear business goals that connect directly to product strategy. You need prototyping fast enough to test ideas before committing to them.

Investment needs to shift toward the new bottlenecks. Quality Assurance engineers who think like security researchers. Architects who design for verification, not just functionality. Product Managers who are less focused on writing specs and more focused on identifying the right problems to solve.

How projects are staffed will change. Do we still need coders in the same way? Quality Assurance engineers? Business analysts? A dedicated governance role? These aren’t rhetorical questions — the answers will shape how you hire, train, and staff projects for the next decade. The teams experimenting with these questions now will have a significant advantage over the ones waiting for the answers to become obvious.

The bottleneck moved. The teams that figure out where it went — and adapt accordingly — will build the right things. That’s always been the harder problem. Now it’s the only problem.

J.D. Salinger wrote one book.

One. His entire life. By most business definitions, he was one of the least productive authors who ever lived.

And yet Catcher in the Rye is considered one of the greatest novels ever written. Millions of copies sold. Decades of cultural impact. Still assigned in classrooms today.

Meanwhile, somewhere out there is an author who published 200 books. You’ve never heard of them.

So who was more productive?

The Problem With How We Measure Output

In business — especially in tech — we’ve often defaulted to quantity as a proxy for productivity. Lines of code. Story points. Tickets closed. Features shipped. The more, the better.

The problem is we’ve confused output with value.

You don’t know if something mattered until after the fact — sometimes long after.

IBM famously compensated engineers by lines of code. You know what they got? A lot of lines of code. Most of it noise.

The Spray-and-Pray Trap

There’s a competing school of thought: just do a lot of things, and eventually something will stick.

Throw enough at the wall. Ship fast. Iterate constantly. The startup mantra.

And look — there’s something to that. Iteration matters. Speed matters. But iteration without depth is just activity. And activity is not the same as progress.

The real question is: when do you iterate fast, and when do you go deep?

That distinction matters enormously — and most leaders never ask it.

Start With Real Pain

Here’s where Steve Jobs and J.D. Salinger actually had more in common than you’d think.

Jobs didn’t run focus groups. But he wasn’t operating on pure whimsy either. He identified a real, specific pain point: people’s relationship with technology was frustrating, clunky, and broken. Then he trusted his intuition to solve it his way.

Salinger did the same thing, just in a different domain. Post-war America had a cultural pain point — alienation, phoniness, the difficulty of growing up. He felt it deeply and wrote from that truth.

The formula isn’t magic. It’s this:

1. Identify a genuine pain worth solving
2. Trust your intuition on the solution — don’t let focus groups water it down
3. Ask if it’s economically viable after you’ve confirmed the pain is real

Most companies do this backwards. They start with what they can monetize, then go looking for problems that fit.

The Focus Group Trap

Here’s the thing about asking people what they want: they’ll tell you. And they’ll be wrong.

There’s a famous example where a focus group was asked: red toy or blue toy? Everyone said red. Then they left a bin of both toys out — and everyone took blue.

Henry Ford said it best: “If I had asked people what they wanted, they would have said faster horses.”

People can’t see solutions that don’t yet exist. They can only describe the world as it is.

A Toyota engineer spent over a year just living with American families before redesigning the Sienna minivan. Not asking. Watching. He observed where they put their cups, how they loaded groceries, how they moved through their days. He saw pain points families had accepted as just the way things were — because they didn’t know a better design was possible.

That’s not scalable. It’s not efficient. And it’s exactly why most companies don’t do it.

But it’s also why that minivan was a hit.

What AI Changes — And What It Doesn’t

Here’s what’s different now: building is cheap.

AI has dramatically compressed the cost of making things. In software especially, you can ship faster than ever. The constraint is no longer “can we build it.”

The constraint is now: should we build it, and what should we build?

That’s a decision problem. And decisions require something AI can’t fake: genuine empathy, human judgment, and real understanding of what people actually need.

AI can analyze patterns in data. It could theoretically watch ten thousand minivans and surface behavioral trends. But it can’t interpret what those patterns mean. It can’t know that an awkward reach for a cup holder is a pain point worth solving — or feel the significance of that moment the way a human engineer can.

The Depth Question

So back to Salinger.

Maybe the real lesson isn’t that he was unproductive. Maybe the lesson is that he was working on a different problem than most people.

He wasn’t optimizing for output. He was trying to capture something true.

And when you create something that captures a true human experience — a real pain, a real feeling, something people recognize in their bones — that’s when the impact outlasts the effort.

That’s not anti-productivity. That’s the highest form of it.

The question worth asking isn’t “how much did we produce today?”

It’s: did we solve something that actually mattered?