July 3, 2026

AI for the Over 40 – Week 28: When "Required" Doesn't Mean "Unchangeable"

Every organization has them: the activities nobody really believes in, but everyone participates in anyway.

Performance reviews. Strategic planning cycles. Compliance training. Budget reconciliation rituals. The annual or recurring processes that consume enormous time and energy while everyone involved quietly acknowledges they are not producing what they are supposed to produce.

We complain about them. We roll our eyes. We go through the motions. Then we do it all again next year, often in almost exactly the same way.

Last week, I shared the paradigm shift behind the AI career development system I started building: what if performance evidence was collected by you throughout the year instead of about you at year-end? This week, I want to share what happened when I actually tried to build it.

The implementation taught me lessons at two levels. There were practical insights about building AI tools for organizational use, but there was also a broader realization about why we accept broken processes as permanent in the first place.

The tax we’ve all agreed to pay

Performance management at most organizations is a tax.

I do not mean that metaphorically. It is a real cost: hours multiplied by people multiplied by fully loaded labor rates. In my organization alone, the annual process consumes thousands of hours across Career Advisors and advisees.

If that investment consistently produced what it was supposed to produce, such as genuine development, fair evaluation, motivated employees, and better career conversations, it would be worth every hour. But most of us know it does not work that way, at least not consistently or reliably.

Instead, we get the year-end scramble. The reconstructed accomplishments. The carefully crafted language is designed for an audience rather than for reflection. The ratings that can feel like conclusions in search of justification.

I covered the philosophy last week: the paradigm inversion, the “Start at Developing” principle, and why accountability needs to shift more toward the individual. This week is about what happened when that philosophy met reality.

What building taught me

I spent the better part of a week creating an AI-powered career development system and most of a weekend debugging it. What I learned went well beyond performance management.

The first thing I ran into was the gap between an elegant idea and a messy reality. My original design assumed Microsoft’s Custom Copilot Studio agents could search email and Teams data the same way M365 Copilot does. They could not, at least not with my licensing, in my environment, at the moment I was building. I spent hours designing toward a capability that was theoretically possible, but not actually available to me.

That distinction matters. Infrastructure literacy is not just knowing what the technology might be able to do someday. It is knowing what is available to you right now, with your current tools, licenses, policies, and constraints.

Once I realized seamless automation was not going to work, I had to redesign the system. Evidence collection would happen through M365 Copilot, which had the search capabilities I needed, while the coaching and analysis layer would run in a separate approved LLM.

At first, that felt like a compromise. But the more I worked with the design, the more it started to look like an improvement.

The separation meant that advisees had to review their evidence before analysis. They could add context that the AI missed, remove noise, and understand what was happening, rather than trusting invisible magic. It also meant the analysis layer was not locked to a single platform, so an organization could use whichever approved LLM best fit its environment.

In other words, the compromise produced a system that was more trustworthy and flexible than my original seamless vision probably would have been.

Moving from prototype to production

The next lesson came when I moved from prototype thinking to production thinking. When I tested the same prompt with different LLMs, I got wildly different outputs. Dimension names varied. Template structures changed. Critical checkpoints were skipped. For personal use, that kind of variability is annoying. For organizational deployment, it is a dealbreaker.

If advisees are producing reports with different terminology and inconsistent formats, the system creates confusion rather than clarity. Making AI reliable for repeatable use required prompt engineering that felt almost comically explicit. It was not enough to say, “Use the official dimension names from the framework.” I had to embed the exact names in a table and add language like, “Do not rename these dimensions, create practical buckets, or substitute alternative categories.”

Back in Week 8, I wrote about conversational, human-centered prompting and treating AI as a collaborator rather than a code executor. That approach still works beautifully for exploration and ideation. But production workflows need something different. They need explicit constraints, embedded definitions, verification checklists, and enforcement language.

Both approaches are valid. The mistake is assuming one prompting style works for every use case.

The final lesson came from early user feedback. Some advisees testing the system said, “This is really cool.” That was nice to hear, but novelty fades quickly. The more important feedback was, “It has helped me think about my work in a different way and how it connects to different development dimensions.”

That second reaction matters because it points to value. Advisees were not just impressed by the tool. They were seeing their own work through a development lens and building awareness that they could bring into monthly conversations with their Career Advisors.

“Cool” does not justify the investment. “This changes how I think about my work”, does.

The broader pattern

Each of those lessons applies to anyone building AI tools for team use rather than personal productivity. Platform realities matter. Constraints can improve design. Production consistency requires more rigor than prototypes. And the real measure of value is not whether people are impressed, but whether the tool changes how they think or work.

But building this system also surfaced something I had not expected: a question about why it took me so long to try. I almost did not build it. Not because it was technically difficult. Not because I lacked the skills. I almost did not build it because I had accepted, like everyone else, that performance management was simply what it was.

A tax we pay. A process we comply with. An annual ritual we endure.

The only reason I built something different is that I finally did the math on the cost and could no longer justify continuing to pay it for something that was not working. That made me wonder how many other “required” activities we are accepting without question.

The weekly status reports nobody reads. The approval workflows that add days without adding value. The compliance processes designed for auditability rather than actual compliance. The meetings that exist because they have always existed.

We complain about all of them. We feel powerless to change them. And often, that feeling of powerlessness is wrong.

What makes “required” feel unchangeable

I have been thinking about why broken processes can feel so permanent. Sometimes it is because someone else designed them. The process came from HR, Legal, Corporate, Finance, or “the system,” and challenging it can feel like challenging authority. Even when the process is clearly flawed, it feels safer to comply than to question. Sometimes the issue is that the cost is distributed. No single person bears the full burden. Everyone loses a little time, so nobody owns the total cost. Death by a thousand cuts does not feel like death until someone adds up the cuts.

Improvement can also feel presumptuous. Who am I to redesign performance management? Who am I to question the compliance process? Who am I to change the approval workflow? It is easy to convince ourselves that our job is to participate, not to redesign.

The switching cost can also seem higher than the status quo cost. Learning something new, getting buy-in, managing change, and handling resistance all feel harder than just doing the same thing again.

And finally, we normalize the frustration. We complain about the process for so long that complaining becomes the response. We confuse acknowledging the problem with addressing it.

Every one of these barriers is real. But none of them automatically means the process is unchangeable.

The question worth asking

The question is not, “How do I make this required activity less painful?”

That question accepts the activity as given and optimizes around the edges. It might lead to a better form, a cleaner template, a shorter meeting, or a slightly improved workflow. Those improvements can help, but they rarely change the underlying experience.

A better question is, “What would this look like if it actually worked?”

That question challenges the premise. It creates space for redesign instead of refinement. It forces you to define the outcome the process was supposed to create before you start improving the mechanics.

When I asked that question about performance management, the answer became much clearer. Evidence would be collected continuously rather than reconstructed annually. The trajectory would be visible to the advisee throughout the year rather than revealed at the end. Development conversations with Career Advisors would be driven by insight rather than obligation.

The technology to enable that already exists. The real barrier was not capability. It was the assumption that meant unchangeable.

Your Week 28 Challenge: Audit your required activities

This week, look at the mandatory processes you participate in and identify the organizational taxes you have been quietly paying.

Start by making a list. What are the required activities that consume significant time without producing proportional value? Performance reviews, status reporting, approval workflows, compliance rituals, recurring meetings, budget processes, planning cycles, or anything else that fits your context.

Then pick one and do the math. Choose the process that frustrates you most and calculate the real cost. How many people participate? How much time does each person spend? How often does it happen? What is the organization actually investing?

Once you see the cost, ask what “actually working” would look like. Do not start with incremental improvement. Ask what the process would feel like if it delivered the outcome it was supposed to deliver. What would participants experience differently? What decisions would be better? What value would be created?

Then notice where you feel powerless. What is stopping you from building toward that better version? Is it technical capability? Authority? Buy-in? Risk? Or is it simply the assumption that because the process is required, it cannot be changed?

Finally, challenge one assumption. Do not start with “redesign performance management.” Start with something smaller, like, “What if I tracked my own development evidence for a month and saw what that revealed?” The goal is to begin where you have control.

You do not need to fix every broken process this week. You just need to notice how many processes you have been accepting as unchangeable that are actually just unchanged.

The Bottom Line

I spent a week building an AI career development system. Along the way, I learned about platform limitations, constraint-driven design, production prompt engineering, and the gap between prototype and deployment. Those lessons will shape how I approach the next organizational AI tool I build.

But the deeper lesson was how long I had been complaining about performance management without seriously questioning whether I could change it. For years, I treated “required” as if it meant “permanent.” It was easier to participate and criticize than to build something better.

AI did not give me permission to redesign a broken process. It gave me the capability. The permission was always mine to take.

What required activity have you been treating as unchangeable? What would it look like if it actually worked? And what is really stopping you from building toward that: capability, authority, or assumption?

The things we are required to do do not have to stay the way they are. Someone designed them. Someone can redesign them. Why not you?

This post is part of the “AI Over 40” series. It first appeared on LinkedIn: AI for the Over 40 [Week 28]: When “Required” Doesn’t Mean “Unchangeable”

Read more AI and Copilot blogs.

Trending Posts