If AI Has the Answers, Who Will Have the Knowledge?

I was sitting on the porch this afternoon, thinking about how much technology has changed during my 27 years in the industry. Things that once took days can now happen in minutes. We can describe an idea to an AI tool and watch it produce something that would once have required several people working together. That is exciting, but it also left me wondering where all this leads.

For generations, people learned a living by working alongside someone who already knew the trade. A carpenter taught an apprentice how to build. A plumber passed along the experience needed to understand what was happening behind the wall. You learned through instruction, repetition, mistakes, and the guidance of someone who had made a few mistakes of their own.

Formal education gave us another way to build knowledge and opened doors to different careers. These paths have existed alongside one another, although somewhere along the way, many people began treating a college degree as the preferred route to success. Meanwhile, we continued depending on people who could build our homes, keep the lights on, and repair what broke. Those skills never stopped mattering.

Now we have AI models and agents that can explain, write, analyze, and carry out parts of a process for us. It raises a reasonable question: how much will we still need to learn ourselves? If a computer can provide the answer and perform the task, will people still see the value in spending years developing the skill?

Having worked as a carpenter before moving into technology, I have respect for what it takes to learn a trade. A generated set of instructions cannot climb into an attic, inspect an unexpected problem, or take responsibility for the finished work. Robotics may change more of that physical work over time, but there is a great deal between describing a repair and completing it properly. I wonder whether practical skills could become even more valuable as more people look toward careers behind a screen.

College faces a different question. Will AI change what students need from an education, how they learn, and what they are willing to pay for it? I expect it will, but I would hesitate to say college will disappear in ten years. I would rather see education evolve so students learn the fundamentals, use modern tools, and demonstrate that they understand the results.

The part that concerns me most is how people will gain experience. A junior developer learns by working through problems, asking questions, and discovering why an approach failed. An apprentice develops judgment through supervised practice. If we hand all the early work to AI, we need to think carefully about where that learning will happen.

Someone still needs to recognize when an answer sounds convincing but is wrong. Someone needs to understand the customer's circumstances, question an assumption, and accept responsibility for a decision. Learning how to prompt a system is useful, but I cannot see it replacing every other kind of expertise. Knowing what to ask often depends on knowing something about the subject in the first place.

There is also the question of dependence. When knowledge lives in people, they can carry it into another job, teach it to someone else, or use it when the systems are unavailable. If we increasingly depend on services we do not control, what happens when access changes or the answer cannot be verified? Knowledge has given people independence for generations, and I think that deserves a place in this conversation.

Looking ahead ten or twenty years, I can imagine a future where AI helps more people learn, build businesses, and accomplish things they once thought were beyond their reach. I can also imagine us becoming very good at requesting results while gradually losing the ability to assess them. Neither outcome is guaranteed. The choices we make about education, mentoring, and work will help determine which direction we take.

I want us to keep moving forward, and I want us to bring the lessons of earlier generations with us. Let AI explain the problem, then give someone the opportunity to work through it. Let experienced people use better tools while continuing to teach those coming behind them. Progress should leave the next generation capable of carrying the work forward.

What is one skill you believe we should keep teaching people to do themselves, even when AI can do much of it for them?

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

From RPA to AI Agents: Are We Automating Away the Human Element?

Over my 27-plus years in technology, I've watched some remarkable changes in how businesses operate. We've gone from people manually entering information into systems, to applications sharing data, to robotic process automation (RPA) handling repetitive tasks. Today, we're entering another chapter with AI agents capable of performing increasingly complex work, making decisions within defined boundaries, and coordinating with other agents to accomplish things that once required entire teams of people.

And I have to say, it's pretty amazing. But there's something I think we should be talking about more often. As we continue to automate more of the work humans have traditionally performed, what does that mean for us in the long run?

RPA Was Just the Beginning

For years, RPA has helped organizations automate repetitive tasks. Think about the employee who spends hours copying information between systems, processing transactions, validating records, or generating reports. RPA allowed us to create software robots that followed defined instructions and performed many of those activities without someone sitting at a keyboard.

The benefits were obvious. Processes became faster, errors could be reduced, and employees could spend more time on work that required judgment and experience. It wasn't perfect, and RPA certainly had its limitations, but it helped demonstrate how much work could be automated when we understood the underlying process.

Now we're seeing something much bigger. Tools like Claude and other AI platforms are helping move automation beyond predefined scripts and rigid workflows. Instead of simply telling a software robot which buttons to click, we can increasingly give an AI agent a goal, access to approved tools, and instructions about what it is allowed to accomplish.

That's a significant change in how we think about automation.

From Individual Tasks to Orchestrated Agents

What fascinates me most is the evolution from automating individual tasks to orchestrating entire workflows using multiple agents.

Imagine a business process that traditionally required several employees. One person receives a request, another validates information, someone else researches an issue, another makes a recommendation, and finally someone completes the transaction.

In the past, we might have automated a few individual steps using RPA. Today, we can design systems where specialized AI agents work together. One agent gathers information, another evaluates it, another prepares an action, and another checks the results before the workflow continues.

When designed properly, these systems can perform work at a scale and speed that would have been difficult to imagine just a few years ago. Traditional RPA still has an important role here, particularly when interacting with older systems or executing predictable actions. AI agents can add flexibility and reasoning capabilities, while orchestration coordinates the activities and human oversight remains part of the design.

We're no longer talking about simply automating a task. We're talking about automating the coordination of work itself.

And that's where things become both exciting and a little concerning.

Those Tasks Used to Belong to People

Here's something worth considering. Many of the activities we're now assigning to AI agents were once someone's daily responsibilities.

The employee who reviewed documents, researched discrepancies, routed assignments, reconciled information, or prepared recommendations was doing work that contributed to the organization. In many cases, those responsibilities were also how people learned the business, developed judgment, and eventually moved into more senior positions.

Today, we can increasingly automate portions of those responsibilities, sometimes combining the work of several traditional roles into a single coordinated system.

From a business perspective, the opportunity is enormous. We can reduce delays, improve consistency, handle larger volumes, and potentially deliver better service to customers.

But from a human perspective, I think we need to ask a different question.

If we automate the work people traditionally used to learn their jobs, how will the next generation develop the experience needed to lead?

That question deserves more attention than it's getting.

What Happens to the Next Generation?

Think about how most of us developed our careers. We started somewhere. We performed repetitive tasks, made mistakes, asked questions, learned from more experienced colleagues, and gradually developed a deeper understanding of the business.

Not every task was exciting. Some were downright tedious. But those experiences often taught us things we couldn't have learned from a textbook or training course.

Now imagine an organization where many entry-level responsibilities are handled by AI agents. The work gets completed, productivity improves, and operating costs may decline.

But where does the next generation of employees begin?

How do they develop the judgment to recognize when an AI agent makes a questionable recommendation? How do they understand a process they've never actually performed? And how do we develop future managers and leaders if we eliminate too many of the opportunities that once helped people gain practical experience?

I'm not suggesting we preserve inefficient processes just to give people something to do. That wouldn't make sense either.

I'm suggesting that as we redesign work, we also need to redesign how people learn, grow, and contribute.

Technology Has Always Changed the Workforce

This isn't the first time technology has changed how people work, and it certainly won't be the last.

Manufacturing automation, personal computers, the internet, cloud computing, and modern SaaS platforms have all changed the responsibilities of employees and the skills businesses need. Some jobs disappeared, others evolved, and entirely new careers emerged.

I believe AI will create opportunities we haven't fully imagined yet. There will be growing needs around agent orchestration, governance, security, process design, system integration, and the human judgment required to oversee increasingly autonomous technology.

But we should also recognize that transitions aren't always easy. New opportunities don't automatically appear in the same locations, at the same salaries, or for the same people whose jobs are changing.

Telling someone whose responsibilities have been automated that technology will eventually create new jobs doesn't necessarily help them today.

That's where leadership matters.

The Responsibility of Leadership

I believe good technology leadership has always been about more than implementing systems. It's about understanding the business, helping people succeed, and making decisions that create lasting value.

As organizations adopt AI agents, leaders should be asking more than how much work can be automated or how much money can be saved.

We should also be asking how employees will adapt, what new skills they'll need, where human judgment remains essential, and how we preserve opportunities for people entering the workforce.

We also need to remember that AI agents aren't employees. They don't carry personal accountability, understand every business consequence, or automatically recognize when a technically correct action might be the wrong business decision.

People remain responsible for the outcomes, even when software performs the work. That means security, governance, auditability, and appropriate human oversight must be part of the design, not something we add after a problem occurs.

The goal should be to use technology to make our organizations better, while also helping our people become better.

Progress Should Include People

I'm genuinely excited about where AI and automation are taking us. The possibilities are extraordinary, and I believe we're still in the early stages of understanding what coordinated AI agents will eventually accomplish.

But I also believe we have a responsibility to think beyond the next productivity improvement or quarterly cost reduction.

What will our workforce look like five or ten years from now? Will we create new opportunities for people to grow, or will we unintentionally eliminate the experiences that helped previous generations become experts? Will technology give employees more meaningful work, or will the pressure to automate everything leave fewer opportunities for people to contribute?

I don't pretend to have all the answers, and I don't think anyone does.

What I do know is that technology has always been most valuable when it solves real problems and improves people's lives.

So yes, let's embrace RPA, AI, Claude, intelligent agents, and the remarkable orchestration capabilities now becoming available. Let's eliminate unnecessary work, improve our processes, and build better products and services.

But let's also remember the people who helped build the businesses we're now automating, and the generations who will need opportunities to build careers in the future.

Because the real measure of progress shouldn't simply be how much work we can automate. It should also be how much opportunity we create for the people who come next.

And that's something I think is worth stopping for a minute to consider.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

The Power of YES: Finding a Way Forward

Most of us would enjoy sleeping a little later, spending more time on the couch, or having a few less things demanding our attention. I certainly understand the appeal. But there is also something rewarding about reaching the end of a difficult day and knowing you worked through something you could have easily put off.

That is what comes to mind when I think about the power of “yes.” Yes, I can take the next step. Yes, I can learn something new. Yes, this is difficult, but I am willing to work through it. That willingness gives us a place to begin, even when we do not have the whole answer.

In technology, product development, and leadership, challenges are part of the work. A customer needs something we have never built before. A solution that looked promising does not work as expected. A project takes a turn nobody anticipated. Those moments test our patience, but they also give us opportunities to improve how we think, communicate, and solve problems.

I appreciate people who can look at a difficult situation and say, “Let’s see how we can make this work.” They might ask questions, bring someone else into the conversation, or suggest a smaller first step. Their attitude helps the team get moving. Sometimes that is exactly what everyone needs.

Saying yes still requires good judgment. We have to be honest about our time, resources, and commitments. A responsible yes might sound like, “We can do that, but we need to adjust the timeline,” or, “Let’s start here and learn before we go further.” That kind of answer gives people a practical path forward and sets them up to succeed.

People who consistently make progress develop the habit of working through challenges. Sometimes they work harder. Often, they find a smarter approach. They ask for help, learn from an unsuccessful attempt, and make adjustments. There is strength in being willing to say, “My first approach did not work. What can I try next?”

Good leadership helps that attitude grow. When someone brings us a problem, our response matters. Listening carefully, asking useful questions, and helping remove an obstacle can give that person the confidence to keep going. Over time, those everyday interactions build a team that trusts its ability to handle difficult work together.

Many challenges turn out to be speed bumps. They slow us down, make us pay attention, and sometimes remind us to change our approach. Others require a longer detour or a different plan. We get better at recognizing the difference through experience and by being willing to learn along the way.

And yes, rest belongs in that picture too. We all need time to recharge and enjoy what we are working for. Progress becomes more sustainable when we take care of ourselves and return with the energy to give our best.

As we head into the weekend, think about something you have been putting off because it feels difficult or unfamiliar. You may not be able to finish it today, but perhaps you can ask the question, make the call, or take that first step.

Give yourself a chance to discover what you can do. A thoughtful “yes” today could be the beginning of something you will be proud of tomorrow.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Before You Add More Work, Ask What Can Come Off

Most teams can tell you what has been added to their workload over the past year. New reports, new meetings, another approval, or an extra step somebody requested along the way. Ask what has been removed, though, and the answer may take a little longer. We are usually much better at adding work than retiring it.

That connects to something I wrote about recently: your team may already know what needs to change. Listening to them is a good start, but we also have to give them room to act on what they know. If every improvement must fit around an already full day, even a useful idea can sit untouched for months. The people who understand the problem are still busy keeping everything moving.

Consider a weekly report that takes an hour to prepare. It may have started for a good reason, perhaps to monitor a difficult rollout or give someone information they couldn't get elsewhere. Years later, the report is still being produced, even though the rollout is finished and the information is available in another system. Somebody continues doing the work because nobody has decided it can stop.

I think this is an important part of leadership across product, development, operations, and the business. We spend a lot of time discussing what our teams should deliver next. We should also understand what they are carrying forward from earlier decisions. Otherwise, a new priority becomes another obligation on top of everything that was already a priority.

That does not mean every old process needs to go. Experience has taught me to respect the history behind how things work. An approval may protect a customer, a review may catch an expensive mistake, and a report may support a decision we do not see from our part of the business. Before removing something, we need to understand who depends on it and what purpose it still serves.

But respecting that history also means being willing to review it. Is the information still being used? Does the same person still need to approve this? Could we meet the original need with less effort? Those are reasonable questions, and the people doing the work should have a place in answering them.

There is an opportunity here for technology teams to deliver real value. Sometimes that means building a better product or improving an integration. Sometimes it means helping the business recognize that a task no longer needs to happen at all. Both require us to understand the work before deciding what to change.

A practical place to start is with one task. Ask your team what they would review first if the goal were to give them a little time back each week. Pick something manageable, understand why it exists, and involve the people who rely on it. If it can change, make the change and check whether it helped.

People want to do useful work, and good teams take pride in doing it well. As leaders, we have a responsibility to make sure their time goes toward work that still matters. Before we ask them to take on the next thing, it is worth asking what they no longer need to carry.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Your Team May Already Know What Needs to Change

A process can look perfectly reasonable until you sit beside the person who has to use it every day. The steps are documented, the application is running, and the reports say the work is getting done. Then someone shows you the spreadsheet they keep on the side, the information they enter twice, or the phone call they make because two systems do not quite agree. Suddenly, you understand why something that should take ten minutes takes most of the morning.

I have written recently about workarounds and the people whose knowledge becomes part of the system. There is another side to that conversation that deserves attention. Those same people may already understand what needs to change. We just need to make time to ask them, and be willing to hear the answer.

Over my 27 years in technology, I have come to appreciate how much you can learn from the people closest to the work. Product leadership, development, operations, support, and the business all see different parts of the same problem. A developer may understand why an application behaves a certain way, while the person using it understands what that behavior costs them throughout the day. We need both perspectives to make a useful decision.

Consider a customer service team that has to check several screens before answering a routine question. Each screen may serve a legitimate purpose, and each system may be working exactly as designed. But the customer is still waiting while someone gathers information that could be easier to find. If we only ask whether the systems are working, we can miss whether they are helping people do their jobs.

That is why I like a simple starting point: “Show me how you do this.” Let someone walk through the actual work, including the parts that never made it into the process document. Ask where they have to stop, what they have to check, and what they wish they did not have to do twice. Give them enough time to explain why those steps exist before deciding which ones should change.

There is a responsibility that comes with asking. If someone takes the time to explain a problem, they deserve more than a polite thank you followed by silence. We may not be able to fix everything immediately, and there may be constraints they cannot see from their part of the process. Good leadership means explaining those constraints, agreeing on what can happen next, and following through.

Experience matters here, too. An older process may contain a safeguard that was added after a costly mistake, or an exception that still serves an important customer need. The person who remembers that history can help us improve the process without creating the same problem again. Progress is much easier when we understand what we are building on.

Sometimes the right improvement is a product change. Sometimes it is clearer ownership, better training, or removing a step that no longer serves a purpose. The size of the change matters less than whether it makes the work more reliable and gives people time back. A small improvement that helps every day can be worth a great deal.

This is one of the things I enjoy about bringing people together across technology and the business. Someone understands the need, someone knows the history, and someone else knows how to build a better solution. Leadership helps those people work through the problem together and turn what they know into something useful.

Before the next planning meeting, it may be worth spending a little time with someone who uses the process every day. Ask them to show you where the work gets difficult, and listen carefully to what they explain. Your team may already know what needs to change. A good next step is making sure that knowledge reaches the people who can help.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Great Products Start with People Who Share a Purpose

As we close out the week, I want to recognize the value that product leadership, management, development, and the broader IT team can bring to a company. When people have clear direction, trust one another, and understand who they are working to help, they can accomplish some remarkable things.

Over my 27 years in technology, I have worked with people who bring very different strengths to the table. Some can listen to a customer and uncover a need that nobody has quite put into words. Others can turn that need into a practical plan, build the solution, or keep everything running reliably. Each contribution matters. A great idea needs people who can deliver it, and a great technical solution needs to solve a problem customers actually have.

That is where leadership makes a difference. Good leaders help people understand the purpose behind the work. They make priorities clear, welcome thoughtful questions, and help teams work through obstacles. They also listen when someone closest to the work sees a better approach. Direction matters, but so does giving capable people the support and trust to do their jobs well.

I think of that shared purpose as our north star. When a deadline gets tight or competing requests arrive, we need something to guide our decisions. Who are we helping? What problem are we solving? Will this make the customer’s experience better? Those questions bring the conversation back to the people who will use what we deliver.

Product leadership helps keep customer needs in view. Management brings coordination and accountability. Developers turn ideas into working products. Quality assurance helps us catch problems before customers encounter them. IT, security, operations, and support help make the experience dependable long after the release. The customer may never see all those people, but they experience the results of their work every day.

Some of the most rewarding moments in my career have been surprisingly simple. A customer no longer has to enter the same information twice. A frustrating process becomes easier to follow. A recurring issue finally gets resolved. Someone who was nervous about using a system begins to feel comfortable with it. Those improvements may not make headlines, but they can make someone’s workday considerably better.

Of course, a company needs to make money. Revenue pays the bills, supports employees, and makes future improvements possible. But there is pride and purpose in delivering something that earns a customer’s business. We should want people to feel that the product was worth their investment and that the company behind it cares about their experience.

Every profession has people who fall short. I have also worked with many who care deeply about doing a good job. They take responsibility, share what they know, help a teammate, and keep working until a problem is understood. With strong leadership and a shared direction, that commitment can become a tremendous asset to a company.

A positive team culture grows through everyday actions. It comes from recognizing good work, keeping promises, addressing problems fairly, and making it possible to ask for help. People need to know what is expected of them, and they need to know that speaking up about an obstacle is part of moving the work forward.

As we finish the week, I hope we take a moment to appreciate the people behind the products and services we depend on. The person asking a careful question. The developer improving a difficult workflow. The manager removing an obstacle. The support professional helping a frustrated customer. Their work adds up.

When we give people a clear purpose and help them succeed together, we can build products that serve real needs, strengthen a business, and make someone’s day a little better. That is work worth being proud of.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

When Your Best Employee Becomes Part of the System

I've seen this happen more than once over the years. Something breaks, nobody can quite figure out what's going on, and eventually somebody says, "Call John. He'll know."

Maybe his name isn't John, but almost every company that's been around long enough has one. He's the person who remembers why something was built the way it was, which customer needed that strange exception, or why a process that looks unnecessary absolutely cannot be removed. Having someone like that on your team is incredibly valuable. It can also create an incredible amount of risk.

When Knowledge Becomes Part of the Architecture

We normally think of architecture as applications, databases, integrations, servers, APIs, and all the other pieces that make a system work. But after enough years, people can become part of the architecture too.

The system works because Sarah knows to check something every Tuesday. A deployment succeeds because Mike knows about the extra step that isn't in the documentation. Support gets an unusual customer issue and immediately sends it to David because he's the only person who has seen it before. Eventually those things become normal, and nobody considers them a problem because the process works.

Until Sarah goes on vacation.

The Human Version of Technical Debt

In my last article, I talked about temporary fixes becoming permanent parts of a platform. I think undocumented knowledge works almost the same way.

One person learns something because they had to solve a problem. The next time it happens, everyone goes back to that person. Why spend three hours investigating something when Jennifer can solve it in ten minutes? It makes perfect sense at the time.

But every time we do that without transferring the knowledge, we make Jennifer a little more important to the operation of the system. Eventually she isn't simply an experienced employee. She's a dependency.

This usually doesn't happen because someone intentionally refuses to document what they know. The company is busy. Customers need things. Production issues happen. Projects have deadlines. Writing down something you already know how to do never feels quite as important as solving today's problem.

So we tell ourselves we'll document it later.

Sound familiar?

When Your Best People Become Bottlenecks

There's an irony here. The people most likely to become bottlenecks are often some of your best employees.

They're dependable. They know the product. They understand the customers. They've seen the mistakes before. When something important happens, they're exactly the people you want involved, so we involve them in everything.

Before long, they're answering questions all day, reviewing everyone else's work, joining every important call, troubleshooting production issues, helping Support, helping Product, and helping newer employees understand the system. Then leadership wonders why they aren't getting their own work done.

We've rewarded expertise by making it almost impossible for the expert to escape it.

Documentation Helps, but It Isn't the Answer

The obvious response is, "We need better documentation." Yes, we probably do. But I've also seen companies create hundreds of pages of documentation that nobody reads and that becomes outdated almost as quickly as it was written.

The real goal isn't documentation. The goal is knowledge transfer.

That might mean documentation, but it could also mean pairing people together, rotating responsibilities, or having another developer troubleshoot the problem while the experienced person helps instead of immediately taking over. Sometimes it simply means asking the person who knows something to explain why instead of always asking them to fix it.

There's a big difference between documenting steps and transferring understanding.

Can Someone Else Do It?

I think that's a surprisingly useful question for leaders to ask. If this person were unavailable for two weeks, could somebody else deploy the application? Could somebody else troubleshoot that integration? Could somebody else explain why this business rule exists? Could somebody else work with that important customer?

If the answer is consistently no, you've found organizational risk.

That doesn't mean the employee has done anything wrong. Quite the opposite. It usually means they've become extremely valuable. Our responsibility as leaders is to make sure their knowledge becomes valuable to the organization too.

The Goal Isn't to Make People Replaceable

Whenever this subject comes up, someone inevitably hears "knowledge transfer" and thinks we're talking about making employees replaceable. That's not how I see it.

The person who can solve every problem is valuable. The person who can help five other people learn how to solve those problems is even more valuable.

That's how teams mature. It's also how experienced employees get the opportunity to move forward instead of spending the next ten years being the person everyone calls whenever the same old system breaks.

A Healthy System Should Survive a Vacation

Maybe that's the simplest test. Your employees should be able to take a vacation without checking Teams every few hours. Someone should be able to get promoted without leaving a hole behind them. Someone should be able to retire after twenty years without everyone suddenly realizing that twenty years of business knowledge just walked out the door.

Technology companies spend a lot of time thinking about redundancy. We build redundant servers, storage, networks, backups, failover systems, and disaster recovery plans. Yet sometimes we'll allow one person to be the only person who knows how a critical part of the business actually works.

That's a strange kind of redundancy plan.

So perhaps there's another question we should ask when evaluating the health of an established platform:

What does the system know, and what do only our people know?

Because eventually people move on. The knowledge shouldn't have to leave with them.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/