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/

 

There Is Nothing More Permanent Than a Temporary Fix

I can't tell you how many times over the years I've heard some version of this: "Let's just do this for now, and we'll come back and clean it up later."

I've probably said it myself more times than I'd care to admit. And sometimes that's exactly the right decision. You're trying to get a release out, a customer has a legitimate problem, production is down, or there's a deadline that simply can't move.

The business needs something now, and the perfect solution might take three weeks when a perfectly acceptable solution can be done in three days. So you make the practical decision. You fix it, ship it, and move on.

Then something funny happens.

Nobody comes back.

The Problem Isn't Taking Shortcuts

I don't believe technical shortcuts are automatically bad. I've spent too many years working in technology to believe everything can always be designed perfectly from the beginning.

Sometimes you simply don't know enough yet. Sometimes the business can't wait. Sometimes you have to make a reasonable tradeoff between what you'd like to build and what you can realistically build today.

That's business. The problem isn't the shortcut. The problem is forgetting that you took one.

Six months later, the temporary solution is still there. A year later, somebody builds something else on top of it. Two years later, the developer who originally created it has moved on.

Now a new developer finds it and asks the obvious question: "Why does this work this way?"

And nobody really knows.

The temporary fix has become architecture.

"We'll Come Back to It" Needs a Date

This is where I think organizations can do better. If we're knowingly making a compromise, there should be some recognition that we're borrowing against the future.

Maybe we put it into the backlog. Maybe we document why the decision was made. Maybe we identify what the better long-term solution should look like.

It doesn't need to become a 40-page technical document. Sometimes a few sentences are enough: Here's what we did. Here's why we did it. Here's what we should eventually change.

That little bit of context can be incredibly valuable two years later when someone is staring at the code wondering what the heck we were thinking. Without it, the next person has to reverse-engineer not only the software, but also the decision behind it.

Success Can Actually Make This Worse

This is one of the strange things about successful products. If the temporary solution works, there's less pressure to replace it.

The customer is happy. Production is stable. The next opportunity arrives. Engineering moves on.

Why spend two weeks improving something that's working when Sales has a new customer waiting for a feature? That's a perfectly reasonable question.

But ask it enough times, and eventually the platform becomes a collection of things that were all supposed to be cleaned up later.

That's when technical debt stops being a few isolated compromises and starts becoming the way the organization operates.

Then the Firefighting Starts

Eventually those old decisions begin interacting with one another. Changing one thing unexpectedly affects another. Developers become cautious about certain areas of the application. Testing takes longer because there are more scenarios nobody wants to accidentally break.

Then something fails in production. Everyone jumps on a call. The team investigates. Somebody finds the problem and patches it.

Great. Crisis over.

But here's the question I think we need to ask more often:

Did we fix the problem, or did we create another temporary fix?

There's a big difference. If every production issue results in another patch layered on top of the previous patch, we're not really reducing technical debt.

We're refinancing it.

The Backlog Can Become a Graveyard

Most technology organizations have a backlog filled with good intentions. Refactor this. Improve that. Replace this old process. Add automated testing here. Clean up that integration.

Everyone agrees the work should happen. It just never becomes more important than the next customer request, production issue, deadline, or revenue opportunity.

Eventually the backlog becomes less of a plan and more of a historical record of things everyone agreed were important but nobody ever prioritized.

That's not really an Engineering problem. It's a leadership problem.

If we tell Engineering to address technical debt but allocate 100% of their time to everything else, we've already made the decision for them.

Some Debt Is Worth Carrying

I also don't think every shortcut needs to be revisited. Sometimes the temporary solution turns out to be perfectly adequate.

If it's stable, understandable, secure, supportable, and isn't preventing the platform from moving forward, maybe there are better places to spend the time.

That's another lesson experience teaches you. Not every ugly piece of code needs to be beautiful. Not every old component needs to be modernized. And not every technical debt item deserves to be paid off.

The trick is knowing the difference between debt that's harmless and debt that's quietly accumulating interest.

Leave Breadcrumbs for the Next Person

If I could change one thing about how organizations handle these decisions, it would probably be this: leave breadcrumbs.

Document why. Create the ticket. Write the comment. Explain the tradeoff. And if something really is temporary, give somebody ownership of deciding when it stops being temporary.

Because two years from now, the person trying to understand that decision might not be you.

I've been that person plenty of times. You stare at something and think, "Who would possibly build it this way?"

Then you dig a little deeper and discover there actually was a pretty good reason. Or worse, you discover the reason was simply: "We were going to come back and fix it later."

Later has a funny way of never showing up.

And that's how temporary fixes become permanent platforms.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

When Your Technology Jokes Need a History Lesson

I had one of those moments recently that reminded me just how long I’ve been working in technology. It wasn’t looking at my resume or counting the years. It was making an old technology joke and realizing that some of the people around me had absolutely no idea what I was talking about.

That happens more often these days.

Mention Y2K and I sometimes get a look that tells me they know what it was, but only as something from history. Those of us who were actually working in technology at the time remember it differently. We remember the meetings, checking applications, databases, BIOS dates and reports, and wondering what was going to happen when the clock rolled over to January 1, 2000.

Then there are the really fun conversations.

Mention COBOL or FORTRAN and see who recognizes them. Drop AS/400 into a conversation and eventually someone will ask, “What’s an AS/400?”

That’s when you realize you’re no longer explaining technology. You’re teaching technology history.

“Okay, kids, gather around. Let me tell you about green screens.”

Before long I’m explaining command-line interfaces, floppy disks and why the Save icon that everyone still clicks today looks like a little square thing that many younger people have probably never actually held in their hands.

Then there was one of my personal favorites: the TURBO button.

Yes, computers actually had a button on the front labeled TURBO.

Think about that for a moment. Someone actually decided the computer needed a physical button that essentially asked, “Would you like your computer to go faster?”

Of course I would!

Push that magical button and maybe the little display on the front went from 100 MHz to 110 MHz.

Ten whole megahertz!

We were flying!

Never mind whether the processor could actually take advantage of it. The number was bigger. The TURBO light was on. Therefore, as far as we were concerned, that computer was moving faster.

It may have been the greatest technological placebo ever invented.

And if you really want to find out who has been around for a while, start talking about dial-up Internet.

I can still hear that modem connecting.

Try explaining to someone today that getting on the Internet meant your computer literally used the telephone line to call another computer. Then explain that if someone in the house picked up the phone, your Internet connection could disappear.

Or tell them about trying to free up conventional memory in DOS. Editing CONFIG.SYS and AUTOEXEC.BAT because the program you wanted to run needed just a little more memory. Moving things around, rebooting the computer and hoping you gained enough precious kilobytes to make it work.

Today we talk about cloud computing, SaaS platforms, APIs, containers, artificial intelligence and systems capable of doing things in seconds that would have sounded like science fiction when many of us started.

And I think that is one of the things I appreciate most about having spent more than 27 years in this industry.

I’ve had a front-row seat.

I remember Y2K. I remember COBOL and FORTRAN. I remember the AS/400. I remember DOS, floppy disks and dial-up. I remember when megabytes sounded impressive.

And yes, I remember the TURBO button.

So when I make one of my old technology jokes at work and someone gives me that confused look, I’ve learned to smile.

Some jokes simply require 27+ years of prerequisite experience.

And for the record, I still believe that TURBO button made the computer faster.

You’ll never convince me otherwise.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Being a Senior Developer Is About More Than Writing Better Code

Being a Senior Developer Is About More Than Writing Better Code

One thing I have learned over the years is that the word "Senior" in Senior Developer shouldn't simply mean someone who has been writing code longer. Experience certainly matters. Technical knowledge matters. Knowing languages, frameworks, databases, APIs, and architecture matters. But I think there is something else that separates a truly senior developer from someone who is simply an experienced programmer.

It is judgment.

A junior developer is often focused on completing the task in front of them. There is nothing wrong with that. We all started there. Here is the requirement. Here is the ticket. Build it, test it, and move it forward.

As developers gain experience, though, I expect the questions to change. Should we be doing this? What else could this change affect? Does something like this already exist elsewhere in the application? What happens to existing customers? What happens to the database? Could this introduce a security problem? How will Support troubleshoot this six months from now? What happens when the next developer has to modify it?

Those questions aren't necessarily written in the ticket, but they can be just as important as the requirements that are.

Senior Developers See Beyond the Ticket

One of the biggest differences I see between junior and senior thinking is the ability to look beyond the immediate assignment. A ticket might say, "Add this field." That sounds simple.

But where does the data come from? Where is it stored? Who can see it? Can it be changed? Should changes be logged? Does it need to appear in reports? Does an API need to expose it? Will another system depend on it later?

Suddenly, "add a field" isn't quite as simple as it sounded.

A senior developer understands that software is interconnected. Changing one thing can have consequences somewhere else, and those consequences aren't always obvious.

Sometimes the Best Developer Is the One Who Slows Things Down

This might sound strange in an industry obsessed with speed, but sometimes the most valuable person in the room is the one who says, "Before we build this, let's make sure we understand the problem."

That isn't resistance. That is experience.

I'd rather spend another hour understanding a requirement than spend the next three weeks fixing something we shouldn't have built that way in the first place. I've said before that we shouldn't automate bad processes. The same principle applies here. Writing code faster doesn't help much if we're solving the wrong problem.

Ownership Matters Too

I also believe seniority comes with ownership. When something breaks in production, the question shouldn't immediately be, "Whose ticket was this?" The better question is, "What happened, how do we fix it, and how do we prevent it from happening again?"

Good senior developers help junior developers understand why something happened instead of simply fixing it for them. They document what they learn. They question patterns that repeatedly create problems. They help improve the process, not just the code.

Most importantly, they understand that their responsibility doesn't necessarily end when the code is merged. The software still has to live in the real world.

AI Makes Judgment Even More Valuable

This becomes particularly interesting as AI continues changing software development. AI can already generate code remarkably quickly, and that capability is only going to improve.

So if writing code becomes easier and faster, what becomes more valuable?

Judgment.

Understanding architecture. Understanding customers. Recognizing risk. Knowing when a solution is becoming unnecessarily complicated. Seeing how today's decision could become tomorrow's technical debt. And sometimes knowing when not to write code.

I don't think AI diminishes the importance of senior developers. I think it makes genuine senior-level thinking even easier to recognize.

Because being senior was never supposed to mean simply being the fastest person at the keyboard.

It means understanding what happens after you press Enter.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Lessons From 27+ Years in Technology - Part 3 of 3

From Building Things to Building Teams

In the first two parts of this series, I talked about going from building houses to becoming a Web Developer and about spending more than 27 years adapting as technology continually changed.

But there's another change that happened along the way.

My definition of what it means to build something changed.

Early in my career, much of my value came from what I could personally do.

Could I write the code?

Could I troubleshoot the problem?

Could I configure the system?

Could I figure out why something wasn't working and fix it?

Those skills mattered, and that experience still matters today.

But somewhere along the journey, I realized my greatest contribution wasn't necessarily going to come from personally doing every technical task.

It was going to come from helping other people succeed at doing them.

That's a very different skill.

If I'm leading developers, I want developers who are better developers than I am.

If I'm working with database professionals, I want people who understand databases more deeply than I do.

I want infrastructure and security people who will challenge my assumptions. I want product people who understand the customer. I want people earlier in their careers bringing new ideas, new technologies, and different ways of thinking to the table.

I don't need to be the smartest person in the room.

I need to help create a room where smart people can succeed together.

That means providing direction without trying to control every decision.

It means asking questions.

It means removing obstacles.

It means recognizing when someone needs help and when they need room to figure something out themselves.

It means allowing people to challenge you.

And sometimes it means letting someone make a mistake, helping them understand what happened, and giving them another opportunity.

This is also where I've learned that product management and people management are very different things.

Product management asks: What should we build? Who are we building it for? What problem are we solving? Why does it matter?

People management asks: Does the team understand where we're going? Do they have what they need to succeed? Are we developing people or simply assigning them work? Are we creating future leaders?

Both matter.

And when you're leading technology organizations, eventually those worlds meet.

Sometimes you're creating a new product.

Sometimes you're fixing one that isn't working.

Sometimes you're modernizing something that has served the business well for years but needs to evolve.

And sometimes you're evaluating something completely new, like AI, and trying to determine where it genuinely belongs.

My job today isn't necessarily to personally write every line of code, configure every server, or know every command.

There are talented people who can do those things far better than I can.

My job is to bring those people together and help point them toward the goal.

When I think back to where this journey started, there's something almost fitting about it.

I started out building houses.

Then I learned how to build technology.

Eventually, I learned how to build products.

And somewhere along the way, I learned that one of the most rewarding things you can build is a successful team.

The tools have certainly changed over 27+ years.

I'm sure they'll change many more times before I'm finished.

That's okay.

I'm still learning.

I'm still adapting.

And I'm still interested in figuring out what we can build next.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Lessons From 27+ Years in Technology - Part 2 of 3

The Technology Changed. The Need to Keep Learning Didn't.

In Part 1, I talked about starting my career as a carpenter building houses in the Washington, D.C. area while going to school and trying to find my way into technology.

Eventually, I got my opportunity as a Web Developer during the dot-com boom and Y2K era.

That was more than 27 years ago.

A lot has changed since then.

I've watched technologies that were once considered cutting-edge become obsolete. I've watched development languages and frameworks come and go. I've watched infrastructure move from physical servers to virtualization and the cloud. I've watched software evolve into SaaS platforms, mobile become part of everyday life, automation change business processes, and now artificial intelligence begin changing how we work again.

Every one of those changes required learning something new.

And I'm still learning today.

I use AI regularly. I'm interested in what it can do, where it can improve productivity, and how it can change the way we develop products and solve business problems.

But experience has also taught me not to confuse new with better.

That's an important distinction.

After enough years in technology, you start recognizing patterns.

I've seen organizations automate bad processes instead of asking whether the process itself should exist.

I've seen teams repeatedly fix symptoms because nobody had the time, authority, or inclination to find the root cause.

I've seen technical shortcuts that saved a few days eventually cost months.

I've seen organizations choose technology first and then try to figure out what business problem it was supposed to solve.

The names of the technologies change, but many of the underlying problems don't.

That's where I believe experience becomes particularly valuable.

Experience doesn't mean walking into a room already knowing the answer.

If anything, experience has taught me to be more comfortable saying, "I don't know. Let's figure it out."

But it has also taught me which questions we should probably ask before we start looking for the answer.

What problem are we actually trying to solve?

Why are we doing this?

Who does it help?

Are we fixing the root cause or another symptom?

Are we making something better, or simply making it newer?

And increasingly today: Are we using AI because it genuinely improves the outcome, or because AI happens to be the technology everyone is talking about?

Those questions aren't anti-technology.

They're exactly the opposite.

Technology is incredibly powerful when we apply it to the right problems.

I've spent more than 27 years watching the tools change, and I expect they'll continue changing faster than ever.

I'm not an expert in every new programming language, platform, framework, or AI tool that appears.

I don't need to pretend that I am.

What I do need to do is remain curious enough to learn, experienced enough to ask questions, and humble enough to surround myself with people who know things I don't.

Because after all these years, one lesson has remained remarkably consistent:

The best technology professionals aren't the people who already know everything. They're the people who never stop learning.

In Part 3, I'll talk about another change that happened along the way.

At some point, my career became less about the things I could personally build and more about the people I could help build them.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Stop Calling Every Old System "Legacy"

There’s a word in technology that I think we use far too casually: legacy. A system has been around for ten years? Legacy. It uses an older programming language? Legacy. The interface looks dated? Definitely legacy. Someone joins the company, sees technology they wouldn’t choose if they were starting today, and suddenly the conversation becomes, “We need to replace this.”

Maybe we do. But I think we need to be careful about confusing old technology with unhealthy technology. They aren't necessarily the same thing.

Old Doesn't Automatically Mean Broken

I've worked around technology long enough to remember plenty of platforms, programming languages, databases, operating systems, and architectural approaches that were once considered modern. Eventually, everything becomes old. That doesn't mean it stops working.

There are systems running businesses today that have been operating successfully for ten, fifteen, twenty years or longer. They process transactions, manage customers, handle complex business rules, integrate with other platforms, and generate revenue every single day. Some of them aren't pretty, and some certainly need modernization, but age alone isn't a business case for replacement.

The question shouldn't be “How old is it?” The question should be “Is it preventing us from going where we need to go?”

Sometimes Old Software Is Old Because It Works

Software that has survived for fifteen years has probably encountered an enormous number of real-world situations. Customers found edge cases. Developers fixed bugs. Business rules changed. Regulations changed. Integrations evolved. Production failures taught the organization lessons.

Multiply that by thousands of changes over many years and something interesting happens. The old system becomes more than source code. It becomes a record of what the business has learned.

The problem is that much of that knowledge may never have made it into formal documentation. It's simply in the software.

The Ugly Code Might Be Trying to Tell You Something

Every experienced developer has opened a piece of code and wondered, “Why on earth did somebody do it this way?” Sometimes the answer really is poor design. But sometimes there was a very good reason.

Maybe a major customer required something unusual. Maybe an external system behaved differently ten years ago. Maybe there was a regulatory requirement. Maybe someone discovered a production edge case at 2:00 in the morning and fixed something that prevented a serious business problem.

Years later, the comment is gone. The developer is gone. The ticket may be gone. The code remains.

That's why I get nervous when someone looks at an established platform and immediately concludes, “This is terrible. Let's rewrite it.” Before removing something we don't understand, perhaps the first question should be: “Why is it here?”

Modern Technology Can Still Produce Bad Software

We sometimes assume that replacing an older platform with modern technology automatically creates a better product. It doesn't.

You can build an unmaintainable system using the newest framework available. You can create poor architecture in the cloud. You can build technical debt with microservices. You can automate a bad process. You can create an elegant new user interface sitting on top of poorly understood business logic.

Modern tools give us tremendous capabilities, but technology doesn't compensate for weak product governance, poor architecture, inadequate testing, unclear ownership, or constantly changing priorities. A new technology stack placed inside an unhealthy development organization will eventually become somebody else's legacy platform.

So What Actually Makes a System “Legacy”?

For me, the more useful definition has very little to do with age. I'd start looking seriously at modernization when the platform is creating measurable constraints on the business.

Maybe the technology is no longer supported. Maybe security risks can no longer be reasonably mitigated. Maybe finding people who understand the technology has become increasingly difficult. Maybe integrations with modern systems are becoming impractical. Maybe the architecture prevents the company from scaling. Maybe development velocity has deteriorated to the point where meaningful product changes take far too long. Maybe operating the platform costs significantly more than a modern alternative would.

Those are business problems. “It's old” isn't.

Modernization Doesn't Have to Mean Replacement

The choice doesn't always have to be “keep everything exactly as it is” or “throw everything away and start over.” There's a lot of territory between those two extremes.

You can replace individual components, refactor high-risk areas, introduce APIs around older functionality, improve automated testing, modernize deployment processes, move appropriate workloads to newer infrastructure, improve monitoring, or gradually separate parts of a tightly coupled application.

In other words, modernize intentionally instead of replacing emotionally.

That approach isn't as exciting as announcing a completely new platform, but it can be dramatically less risky.

The Rewrite Has Its Own Technical Debt

One of the ironies of replacing an established system is that the new platform starts accumulating technical debt almost immediately. Requirements change while you're building it. Customers still need features. Business priorities change. Developers make compromises to hit deadlines.

Meanwhile, you're maintaining the existing platform and building its replacement. Now you have two systems, two sets of problems, and potentially two engineering efforts competing for resources.

This doesn't mean rewrites should never happen. Sometimes they absolutely should. It means the decision needs to be based on business constraints and technical evidence rather than frustration with the age of the existing system.

Respect the Knowledge Before You Replace the Technology

I've spent enough years in technology to appreciate new tools. I've also spent enough years in technology to respect old ones.

Before replacing an established system, understand it. Document it. Identify the business rules buried inside it. Understand the integrations. Find the edge cases. Talk to the people who have supported it. Figure out which problems actually come from the technology and which come from the processes surrounding it.

Then decide what needs to change.

Sometimes modernization means building something new. Sometimes it means replacing part of what already exists. And sometimes the smartest decision is improving the system you already have.

Old Isn't the Enemy

Technology should evolve. Platforms should improve. Organizations should continuously modernize. But modernization should have a purpose.

We shouldn't replace systems simply because they're old any more than we should keep them simply because they've always worked. Both can be emotional decisions.

The better question is: “What is preventing this platform from supporting where the business needs to go next?”

If the answer is the technology, modernize it. If the answer is architecture, address the architecture. If the answer is process, fix the process. If the answer is governance, improve governance.

And if the system is still reliable, supportable, secure, scalable, and capable of evolving, maybe calling it “legacy” says more about our perception of the technology than the actual health of the product.

Old software isn't necessarily technical debt. Sometimes it's simply software that survived.

This follows the principle in your original presentation that mature organizations use incremental modernization and targeted refactoring rather than assuming an aging platform automatically requires wholesale replacement.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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