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/

 

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/

 

We Spent 20 Years Locking Down Users. Now We're Giving the Keys to AI.

Let me start by making something very clear: I am a huge believer in AI. I use it, I see tremendous value in it, and I think tools like ChatGPT, Claude, Copilot and whatever comes next are going to fundamentally improve how we work.

AI can make people faster, eliminate repetitive work, help us analyze problems, write software, research ideas, improve customer service and automate processes that have frustrated businesses for years. The argument I'm making isn't that AI is bad. The argument is that something this powerful shouldn't be unchecked.

For the last 20-plus years, IT organizations have spent enormous amounts of time limiting what users, applications and systems are allowed to do. We removed local administrator rights, implemented MFA, restricted Remote Desktop, created firewall rules, segmented networks, introduced conditional access, built privileged accounts and implemented change control.

Behind nearly all of those decisions was one very old security principle: Give someone only the access they actually need. Least privilege.

But now something interesting is happening. After spending decades locking everything down, we're beginning to hand increasingly powerful access to AI.

AI Is No Longer Just Answering Questions

When ChatGPT and Claude first appeared, most people interacted with them primarily as assistants. Ask a question, get an answer. Write an email, summarize a document, analyze some code or brainstorm an idea.

We're quickly moving beyond that. AI is becoming agentic. Instead of simply telling us what to do, we're increasingly allowing AI to do things for us.

Give AI access to email. Then calendars. Then OneDrive or Google Drive. Then GitHub. Then the CRM. Then the browser. Then local files, APIs and business applications.

Every one of those connections makes AI more useful, and that's a good thing. But every connection also gives AI more authority.

At some point, AI isn't simply another application. It's another identity inside the business, and potentially a very powerful one.

We've Seen This Movie Before

Anyone who has worked in IT long enough remembers when Remote Desktop was primarily viewed as a convenience. Why drive somewhere when you can remotely connect to the computer?

Remote access wasn't bad technology. It was incredibly useful technology. The problem came when powerful remote access was deployed without adequate controls. Attackers learned to exploit poorly secured remote access for compromised systems, ransomware, credential theft and lateral movement.

The lesson wasn't "Stop using remote access." The lesson was "Powerful capabilities require appropriate controls."

So we adapted. VPNs, MFA, firewalls, conditional access, network segmentation, privileged access management and logging. We didn't abandon the technology. We learned how to use it responsibly.

AI deserves exactly the same approach.

The More AI Can Do, the More Governance Matters

Imagine an AI agent with access to your email, files, source code, customer database, CRM, accounting system, browser, internal applications and APIs.

Now ask yourself: If this were a human employee, would I give one person unrestricted access to all of this?

Probably not.

That doesn't mean we shouldn't connect AI to these systems. There are enormous productivity benefits in doing so. But access should be intentional.

If AI needs to read something, does it also need permission to modify it? If it needs to prepare an email, does it automatically need permission to send it? If it analyzes financial information, does it need authority to execute a transaction? If it examines production systems, does it need permission to make production changes?

Those aren't arguments against AI. They're the same access-control questions IT has been asking for decades.

Shadow IT Is Becoming Shadow AI

There's also a much more immediate challenge. While executives and IT departments debate which enterprise AI platforms they should approve, employees are already using AI.

Someone uploads an Excel spreadsheet to a personal AI account. Someone pastes company information into an AI assistant. A developer installs an AI coding tool. Someone connects an AI assistant to cloud storage. Someone else gives an AI agent access to their browser.

We've dealt with Shadow IT for decades. Now we're beginning to deal with Shadow AI.

Simply banning AI probably isn't the answer. If a technology genuinely makes people more productive, people will find ways to use it. Organizations should instead provide employees with approved, secure ways to use these tools.

Governance should enable AI, not prevent it.

Use AI Aggressively. Govern It Intelligently.

There are two extremes. One organization says, "AI is too dangerous. Nobody can use it." Another says, "AI is amazing. Connect it to everything."

Neither approach makes much sense.

The better answer is somewhere in the middle: Use AI aggressively, but govern it intelligently.

Give employees access to approved AI platforms. Protect corporate information. Apply least privilege. Require human approval for consequential actions. Log what AI systems access and change. Review integrations before connecting AI to critical systems. And don't give an AI system authority simply because giving it that authority is convenient.

We've traditionally managed identities for employees, administrators, contractors, applications, service accounts and devices. Now we're adding another: AI agents.

What systems can the AI access? What information can it read? What can it modify? What actions can it perform? Who authorized those permissions? Can those permissions be revoked? Can we determine what it did afterward?

Those aren't anti-AI questions. They're responsible IT governance questions.

Don't Fear AI. Manage It.

AI has enormous potential, and I believe businesses that embrace it intelligently will have a significant advantage over those that don't.

But embracing AI doesn't mean abandoning decades of good IT practices.

Least privilege still matters. Separation of duties still matters. Change control

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

When Did the Workaround Become the Process?

Every organization has workarounds. A spreadsheet someone created because the system doesn't quite do what the business needs. A service that gets restarted every Monday morning. A report that requires someone to manually combine data from three different systems. A support team that knows exactly what to tell users when a particular error appears. A Product team that has learned not to touch a certain part of the application because "it's always been temperamental."

Individually, none of these things seem particularly alarming. Sometimes a workaround is exactly what you need. Something breaks, the business needs to keep moving, and smart people figure out another way to get the job done. That's a good thing.

The problem starts when nobody comes back and asks: Why are we still doing it this way?

Temporary Has a Way of Becoming Permanent

I've seen this happen countless times throughout my career. Someone creates a temporary process because a system can't handle something. It works. Six months later, people are still doing it. A year later, it's documented. Two years later, a new employee is trained on it.

Eventually, nobody remembers why the workaround exists. It's simply part of the job. And then someone suggests changing it.

The response? "We've always done it this way."

That's when technical debt becomes operational debt. We've taken something that was originally intended to get us through a problem and quietly turned it into a permanent business process.

The Spreadsheet Isn't Necessarily the Problem

Spreadsheets are a great example. I've heard plenty of technology people complain about businesses running important processes through Excel. But Excel isn't necessarily the problem.

The interesting question is: Why did someone need to create the spreadsheet?

Maybe the application didn't provide the information they needed. Maybe two systems couldn't communicate. Maybe the official process took 20 steps and someone figured out how to accomplish the same thing in five. Maybe Product never understood how people actually used the system.

That spreadsheet may be telling you something important. Instead of immediately asking, "How do we get rid of this spreadsheet?" we should probably ask: "What problem did this spreadsheet solve?"

That's a very different conversation.

Your Users Are Often Designing Solutions for You

People are remarkably good at adapting. Give someone a difficult process and eventually they'll figure out an easier way to do it. They'll build spreadsheets, create templates, copy information between systems, develop shortcuts, write instructions for each other, and even learn which buttons they're not supposed to click.

From an IT or Product perspective, it's easy to look at these behaviors and say users aren't following the process. Sometimes that's true.

But sometimes users are telling us something much more valuable: The process isn't following the business.

Those workarounds can become some of the best requirements gathering you'll ever do. Instead of asking users what feature they want next, watch what they're already doing outside the system. There's usually a reason.

The Cost Is Bigger Than the Extra Steps

A workaround that takes five extra minutes doesn't sound particularly serious. But multiply those five minutes across 50 employees, several times a week, for several years. Now it starts getting expensive.

And labor isn't the only cost. Manual processes introduce mistakes. Spreadsheets create multiple versions of the truth. Tribal knowledge creates dependencies on particular employees. Repeated system problems consume support resources. Temporary integrations become permanent architecture.

Eventually, the organization spends a surprising amount of time and money maintaining things nobody intentionally designed. That's the hidden cost of accepting friction as normal.

This Is Where Leadership Matters

Technology and Product leaders shouldn't eliminate every workaround. That's neither practical nor necessary. The job is to recognize which workarounds are telling us something about the health of the organization.

When I see a recurring manual process, support ticket, production incident, or customer complaint, I start asking questions: Why does this exist? How often does it happen? How many people are affected? What does it cost us? What would have to change to eliminate it?

And perhaps the most important question: If we were designing this process today, would we intentionally design it this way?

If the answer is no, then "we've always done it this way" probably isn't a very good reason to keep doing it.

Workarounds Are Useful. Until They're Not.

There will always be temporary fixes, and there should be. Businesses can't stop every time tech

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Your SaaS Business Can Be Profitable and Still Be Technically Unhealthy

One of the most dangerous assumptions a successful software company can make is:

“The numbers look good, so the product must be healthy.”

Revenue is growing. Customers are renewing. EBITDA looks strong. Churn is manageable. The sales pipeline looks promising.

From a financial perspective, everything appears to be working.

Meanwhile, Engineering is struggling to release changes. Support costs are creeping upward. Developers are spending more time maintaining existing functionality. Customer-specific workarounds are multiplying. Innovation is slowing down.

Both things can be true at the same time.

A software business can be financially healthy today while becoming technically unhealthy tomorrow.

Success Can Hide a Lot of Problems

When a business is struggling financially, everyone starts asking difficult questions.

When a business is growing, we tend to ask fewer of them.

That's understandable. Growth validates a lot of decisions. Customers are buying the product. They're renewing. The company is making money.

Something is clearly working.

But success can also give an organization enough financial momentum to carry technical and operational problems for a surprisingly long time.

The platform gets harder to maintain, so we add people.

Support volume increases, so we add support staff.

Development slows, so we hire more developers.

Infrastructure becomes inefficient, so we spend more on infrastructure.

Each response solves the immediate problem.

But eventually someone should ask:

Why does it keep taking more people, more money, and more effort to produce the same result?

That's where the financial conversation and the technical conversation begin to intersect.

Revenue Doesn't Measure Platform Health

Revenue tells us customers are paying us.

It doesn't tell us how difficult the product is to operate.

EBITDA tells us something important about financial performance.

It doesn't tell us whether developers are afraid to deploy on Friday afternoon.

Customer retention tells us customers are staying.

It doesn't necessarily tell us why they're staying.

That's particularly important with mature business software.

Replacing an established platform can be expensive, disruptive, and risky for a customer. Data has to move. Employees need training. Integrations need rebuilding. Business processes need changing.

Sometimes customers remain because they love your product.

Sometimes they remain because leaving is painful.

Those are not the same kind of customer loyalty.

Low churn is valuable, but low churn alone doesn't prove that a product is healthy.

Watch the Cost of Producing Revenue

One metric I think deserves more attention is the effort required to support continued growth.

Imagine revenue increases 20%.

That's great.

But what happened behind the scenes to support that growth?

Did support staffing increase 40%?

Did infrastructure costs increase 35%?

Did Engineering add people while release velocity stayed flat?

Are implementations taking longer?

Are developers spending more time maintaining customer-specific functionality?

Are production incidents becoming more frequent?

Revenue growth is important, but so is understanding what it costs the organization to produce and sustain that revenue.

Growth that continuously increases operational complexity eventually compresses margins.

And at that point, technical debt has stopped being an Engineering problem.

It has become a financial problem.

Technical Debt Behaves a Lot Like Financial Debt

I've always thought the term “technical debt” is useful because the comparison to financial debt is surprisingly accurate.

Debt isn't automatically bad.

Businesses borrow money all the time to accelerate growth. If the return on that investment exceeds the cost of the debt, taking on debt can be perfectly rational.

Technical debt can work the same way.

Maybe you need to ship something quickly to win an important customer.

Maybe you knowingly choose a simpler architecture because speed to market matters more right now.

Maybe you delay some modernization because the business has a critical opportunity.

Those can all be reasonable decisions.

The problem begins when the organization keeps borrowing and never starts paying anything back.

Eventually, you aren't just carrying the original debt.

You're paying interest on it.

In software, that interest appears as longer development cycles, increased testing requirements, more production incidents, higher support costs, slower onboarding, increased infrastructure costs, and engineers spending more time understanding old decisions.

The debt may never appear as a line item on the balance sheet.

But the company is paying for it.

Adding Developers Doesn't Always Make Development Faster

This is another place where financial and technical thinking sometimes collide.

When product delivery slows, the obvious business response is:

“We need more developers.”

Sometimes that's absolutely correct.

But adding people to an unhealthy platform doesn't automatically increase velocity.

New developers have to learn the system. Experienced developers have to train them. Institutional knowledge may exist primarily in people's heads. Development environments may be difficult to configure. Automated testing may be incomplete. Architecture may be inconsistent.

Now the experienced developers who were already overloaded have another responsibility: helping the new developers understand everything.

You increased Engineering expense.

But you didn't necessarily increase Engineering output.

That's an important distinction.

More capacity doesn't fix the friction that consumes capacity.

Sometimes the better investment isn't another developer.

It's making the existing development organization easier to scale.

Innovation Is an Asset Too

There's another cost that's much harder to see.

What isn't getting built?

A company may be profitable while competitors are improving faster.

Customers may still renew while increasingly asking when certain capabilities are coming.

Sales may still close deals while encountering more feature gaps.

Engineering may still deliver releases while spending 80% of its capacity maintaining what already exists.

None of those conditions necessarily create an immediate financial crisis.

That's what makes them dangerous.

By the time declining innovation clearly appears in revenue, the organization may already be several years behind.

The financial impact of technical stagnation often arrives long after the technical warning signs.

Don't Wait for Technology Problems to Become Financial Problems

This is why technical health belongs in executive conversations.

I'm not suggesting CEOs need to review source code or CFOs need to understand deployment pipelines.

They shouldn't.

But leadership should understand whether the technology supporting the business is becoming easier or harder to operate and evolve.

There are some useful questions executives can ask:

How much Engineering capacity is spent maintaining the existing platform versus improving it?

Are support costs growing faster than revenue?

Are releases becoming easier or harder?

Is customer onboarding becoming more standardized or more customized?

Are infrastructure costs scaling predictably with revenue?

How long does it take new developers to become productive?

Are recurring production problems actually being eliminated?

None of these questions require an executive to be deeply technical.

They require leadership to recognize that platform health is business health.

Durable EBITDA Requires Operational Maturity

Cost cutting can improve EBITDA.

Reducing Engineering investment can improve EBITDA.

Delaying modernization can improve EBITDA.

For a while.

But there's a difference between improving a financial metric and improving the underlying economics of the business.

The strongest SaaS organizations don't simply control costs.

They make the platform itself more efficient to operate, support, change, and scale.

That creates a much more durable advantage.

Engineering can deliver faster without proportionally increasing headcount.

Support can serve more customers without proportionally adding people.

Infrastructure scales predictably.

Implementations become repeatable.

Customers receive improvements faster.

That's operational leverage.

And operational leverage is ultimately what turns technical maturity into financial performance.

The Question Behind the Numbers

When leadership reviews the financial performance of a software business, the conversation naturally focuses on revenue, margins, churn, growth, and profitability.

Those numbers matter.

But I'd add another question:

What is happening underneath them?

Are we becoming more efficient as we grow?

Or are we simply throwing more people, money, infrastructure, and workarounds at increasing complexity?

Because those can produce remarkably similar financial results for a while.

The difference becomes obvious later.

One creates a business capable of scaling.

The other creates a business that eventually discovers just how expensive its success has become.

A profitable software company isn't automatically a healthy software company.

The best organizations make sure they're building both.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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