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/

 

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

From Building Houses to Building Technology

I've spent more than 27 years working in technology, and when I look back at where it all started, I'm sometimes amazed at the path that got me here.

My career didn't actually begin in technology. Before I ever wrote code professionally, I was a carpenter building houses in the Washington, D.C. area.

At the same time, I was going to school because I wanted to break into this growing technology industry. I didn't have decades of experience. I didn't have a long list of certifications. I certainly didn't know where the career would eventually take me.

What I had was a willingness to learn, a positive attitude, and the determination to keep pushing forward until someone gave me an opportunity.

Eventually, someone did.

I started working as a Web Developer in the Washington, D.C. area, and it was quite a time to enter the industry. The dot-com boom was underway, businesses were racing to understand this relatively new thing called the Internet, and the world was preparing for Y2K.

Technology was changing incredibly quickly.

Looking back, though, one thing stands out to me about entering the industry during that time.

You weren't necessarily expected to know everything before someone was willing to give you an opportunity.

You needed some skills, of course. But you also needed the ability to learn, the willingness to work, and the persistence to figure things out when you didn't know the answer.

That last part became far more important to my career than I realized at the time.

Technology has a funny way of making today's expertise temporary. Eventually, the language changes. The platform changes. The hardware changes. The methodology changes. Something new comes along and suddenly everyone has something else to learn.

If your entire value is based on knowing a particular technology, eventually that technology is probably going to change.

But knowing how to learn, how to solve problems, and how to keep moving forward when you don't immediately know the answer has a much longer shelf life.

The carpenter who was building houses during the day while trying to find his way into technology couldn't possibly have known what the next 27+ years would bring.

I didn't know that I would eventually work across different industries, technologies, products, and leadership roles. I didn't know how many talented people I would have the opportunity to work with, learn from, mentor, lead, and eventually call friends.

I certainly couldn't have imagined cloud computing, SaaS, modern mobile technology, or artificial intelligence as we know them today.

I was simply trying to get my foot in the door.

Someone eventually opened that door.

The rest was up to me.

More than 27 years later, I think there's still an important lesson in that.

Sometimes potential isn't about everything someone already knows. Sometimes it's about their willingness to learn what they don't.

That willingness helped me move from building houses to building technology.

And as I'll talk about in Part 2, the technology never stopped changing.

Fortunately, neither did my willingness to learn.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

The Most Expensive Problems Are the Ones We Keep Fixing

There is an interesting trap in IT and software development. Sometimes we get really good at fixing a problem. So good, in fact, that we stop asking why we keep having to fix it.

A ticket comes in. Someone recognizes the issue. They know exactly what SQL query to run, which service to restart, which configuration to change, or which workaround to give the user. Problem solved. Ticket closed. Everyone moves on.

Then it happens again. And again. Eventually, what started as an exception becomes routine. That is when fixing the problem can actually become more expensive than solving it.

We Often Measure the Wrong Thing

Most technology organizations measure things like response time, resolution time, ticket volume, SLA compliance, and backlog size. Those measurements are important, but there is another question we should be asking:

Why did this ticket exist in the first place?

Closing 100 tickets quickly may look great on a dashboard. Preventing 80 of those tickets from ever being created is much better.

Think of it like repeatedly putting water into a leaking bucket. At some point, instead of getting better at filling the bucket, you probably need to fix the leak.

Technology organizations aren't much different.

When the Workaround Becomes the Process

Workarounds aren't necessarily bad. Sometimes they're exactly what we need. Production is down. A customer can't work. A critical process has stopped. You get things running again first. That's responsible operations.

The problem begins when the temporary workaround quietly becomes permanent.

Someone documents the workaround. Someone else learns it. Eventually the support team knows it. Then a new employee is trained on it. Before long, the organization has created an entire business process around something that was never supposed to exist in the first place.

At that point, we've stopped treating the workaround as temporary.

We've designed around the defect.

Tribal Knowledge Can Hide the Real Cost

This becomes even more dangerous when experienced employees make recurring problems look easy.

You've probably heard something like, “Oh, when that happens, just ask John. He knows how to fix it.”

That might sound reassuring, but what happens when John is on vacation? What happens when John leaves the company? More importantly, why does John need to keep fixing it?

Good people often compensate for bad processes. Because they're good at it, the organization sometimes doesn't realize how broken the underlying process actually is.

Every Repeat Has a Cost

One recurring problem might only take 15 minutes to resolve. That doesn't sound significant. But suppose it happens four times a week. That's an hour a week, or roughly 50 hours over the course of a year.

Now multiply that across several employees, environments, customers, or systems.

That still doesn't account for interruptions, context switching, investigation time, customer frustration, QA, management attention, or the opportunity cost of what those people could have been doing instead.

Suddenly, the little 15-minute problem isn't so little anymore.

Recurring problems compound.

The Ticket Should Leave Something Behind

This is why I believe a support or production ticket should produce more than a resolution. Whenever possible, it should leave behind knowledge.

What happened? What was the root cause? How was it diagnosed? What evidence confirmed the problem? What was done to correct it?

And most importantly: What would prevent this from happening again?

Sometimes the answer will be a code change. Sometimes it will be architecture or configuration. Sometimes it will be documentation, monitoring, training, or a better business process.

And sometimes the answer will simply be that fixing it permanently isn't worth the investment. That's okay too. The important thing is that we made that decision intentionally instead of allowing a workaround to become permanent simply because nobody questioned it.

Don't Confuse Activity With Progress

There is something satisfying about closing tickets. You can see the queue getting smaller. You can measure it. You can report it.

But activity and progress aren't always the same thing.

A team that closes 1,000 recurring tickets isn't necessarily performing better than a team that identifies the root causes and prevents 500 of those tickets from ever being created.

One team became better at fixing problems. The other became better at eliminating them.

That's an important distinction.

The Goal Isn't Zero Problems

Software will have defects. Infrastructure will fail. People will make mistakes. Requirements will change. Unexpected things will happen.

That's technology.

The goal isn't to create an environment where nothing ever goes wrong. The goal is to make sure we're learning from the things that do.

Because the most expensive problem isn't always the catastrophic outage everyone remembers. Sometimes it's the tiny problem everyone has learned to live with.

The one we've fixed hundreds of times. The one everyone knows the workaround for. The one nobody stops to question anymore.

Sometimes the most expensive problems are the ones we've become really good at fixing.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

I've said this before, and I think it is worth repeating: I am a big believer in AI.

I use it. I see tremendous value in it. I believe it is going to fundamentally change how we develop software, operate businesses, support customers, analyze information, and make decisions.

But there is an important difference between using AI as a tool and allowing AI to operate unchecked. That distinction becomes even more important as AI moves beyond simply answering questions and begins taking actions on our behalf.

AI Hallucinations Are Different When Actions Are Involved
We have all seen examples where an AI confidently provides an answer that simply isn’t correct. That is generally referred to as an AI hallucination.

When AI is being used as a research assistant or a thought partner, the consequences can often be managed. A person reviews the response, recognizes something doesn’t look right, verifies the information, and corrects it. That human review is an important part of the process.

But what happens when AI is no longer just recommending what should happen? What happens when it can actually do it?

Imagine an AI system that can modify a database, deploy code, change a firewall rule, disable a user account, send communications to customers, approve a transaction, or modify production infrastructure.

Now a hallucination isn’t simply a wrong answer on a screen. It can become a wrong action.

The Problem Gets Bigger as AI Gets More Access
There is an old principle in IT security called least privilege. You give a person or system only the access necessary to perform its job. There is a reason we have followed that principle for decades.

We learned, sometimes painfully, that convenience and security do not always point in the same direction. The same thinking needs to apply to AI.

If an AI agent has access to email, databases, source code, production environments, financial systems, customer information, and administrative tools, we should be asking some very traditional IT questions:

What does it actually need access to? What actions can it perform without approval? What requires human authorization? What gets logged? Can its actions be reversed? Who is accountable when something goes wrong?

These aren’t new questions. We have been asking them about users, administrators, applications, APIs, and service accounts for decades. AI shouldn’t suddenly be exempt from those same controls.

Human-in-the-Loop Should Not Be Considered a Weakness
There seems to be a race toward making AI completely autonomous. I understand why. The more AI can accomplish without human involvement, the greater the potential efficiency.

But efficiency should not automatically override control.

For high-impact decisions, having a human approve an AI-generated action may be exactly the right architecture. AI can analyze thousands of records. AI can identify patterns. AI can recommend an action. AI can prepare the change. And then a qualified person can review it and say, “Yes, execute.”

That extra step may add a few seconds or minutes to the process. It may also prevent hours, days, or millions of dollars of damage.

Trust, But Verify
That phrase existed long before artificial intelligence, but it may be one of the most important principles we carry forward into the AI era.

AI does not need to be perfect to be incredibly valuable. People aren’t perfect either. That is why mature organizations build controls around important processes.

We use peer reviews. We use change management. We separate development from production. We use approval workflows. We maintain audit logs. We test before deployment. We back things up. We limit administrative access.

AI should fit into those disciplines rather than bypass them.

The Future Should Be AI With Governance, Not AI Without Humans
I don’t believe the answer is slowing down AI adoption. I believe the answer is becoming smarter about how we adopt it.

AI should eliminate repetitive work, accelerate analysis, help developers build better software, help leaders make better-informed decisions, and allow organizations to accomplish things that previously required enormous amounts of time.

But capability and authority are two different things.

Just because an AI system can perform an action doesn’t mean it should always have the authority to perform that action without oversight.

The companies that ultimately get the most value from AI may not be the ones that simply give it the most access. They may be the ones that build the best guardrails around it.

Because the goal shouldn’t be to remove humans from every process. The goal should be to combine what AI does exceptionally well with the judgment, accountability, and experience that people bring to the table.

AI is an extraordinary tool. But like every powerful tool we have introduced into technology over the years, its value will ultimately depend on how responsibly we choose to use it.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Writing Code Is Not the Same as Building a SaaS Product

One of the biggest misconceptions in software development is that if someone can write code, they can build a software product. They are not the same thing.

A junior developer may be perfectly capable of taking a requirement and turning it into working code. A senior developer starts asking different questions. What happens when this fails? What happens when 10 users become 10,000? How will we support it? How will we monitor it? How do we upgrade it without breaking customers? What happens to the data? Is it secure? And perhaps most importantly: are we solving the right problem in the first place?

That difference becomes even more important when we talk about websites versus true SaaS applications.

A Website and a SaaS Application Are Different Things

Today, there are fantastic tools that allow someone to create a professional-looking website remarkably quickly. AI has made that even easier. But a good-looking interface is only the front door. A true SaaS application has an entire building behind it.

There are databases, APIs, authentication, authorization, security, logging, monitoring, backups, integrations, deployment pipelines, performance considerations, data retention, disaster recovery, scalability, and ongoing support.

Then comes another layer that is sometimes forgotten entirely: the business. Who is the customer? What problem are we solving? How does the customer actually use the product? What happens when their workflow doesn't match the workflow the development team imagined? And how do we continue improving the product without creating so much technical debt that every future change becomes harder than the last?

Junior Developers Build Features. Senior Developers Think About Consequences.

That isn't meant as criticism of junior developers. Everyone starts somewhere, and good junior developers can become outstanding senior engineers. The difference is often experience.

After you have lived through enough production outages, database problems, failed deployments, security incidents, performance problems, and seemingly "simple" changes that unexpectedly affected something else, you start thinking differently.

Instead of asking, "How do I make this work?" you begin asking, "How do I make this work reliably, securely, sustainably, and at scale?"

That is a very different question.

And Then There Is Product Thinking

Some of the best developers I've worked with don't immediately start coding when you give them a problem. They ask questions.

Why are we doing this? Who needs it? What are they doing today? What problem are we actually trying to solve? Is there already something in the platform that does this? What happens six months from now when the business changes?

Sometimes the best technical decision is not writing more code at all.

That kind of thinking is especially important in SaaS because every shortcut eventually becomes somebody's problem. It might become the support team's problem. It might become an infrastructure problem. It might become a security problem. Or it might become technical debt that the development team spends years trying to unwind.

AI Makes This Distinction Even More Important

AI can now generate remarkably good code. It can build interfaces, APIs, database structures, and even entire applications faster than many of us would have imagined a few years ago. I think that's a tremendous opportunity.

But generating code and engineering a sustainable product are still different things.

AI can help us build faster. Experience helps us understand what should be built, how it should be built, and what could go wrong after we build it.

That is why I don't believe the future belongs simply to the person who can write the most code. It belongs to people who understand systems, customers, operations, and consequences—and who can bring all of those things together.

Because ultimately, the goal isn't to build software that works during the demo.

The goal is to build software that still works when the demo is long forgotten and thousands of customers depend on it.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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