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/

 

New Technology, Same Old Process

I've seen this happen more times than I can count.

An organization decides an old system needs to be replaced. The existing system is slow. It's difficult to maintain. People have created spreadsheets and workarounds to compensate for its limitations. Everyone agrees it's time for something new.
So the organization spends months selecting a new platform, implementing it, migrating the data, training employees, and finally going live.

And when everything is finished? They've recreated almost exactly the same process they had before.

They bought new technology. But they kept the old thinking.

“The Old System Did It This Way”

This is one of the most dangerous sentences during any modernization project: “The old system did it this way.”

That statement isn't necessarily wrong. Understanding how the existing system works is important. But it should be the beginning of the conversation, not the end of it.

The next question should be: Why did it do it that way?

Sometimes there is a very good reason. There may be a regulatory requirement, an accounting control, a customer commitment, or a legitimate business rule behind the process.

But sometimes the answer is simply: Because that's what the old system required.

And that's a very different thing.

Workarounds Have a Way of Becoming Requirements

Imagine a system implemented fifteen years ago that couldn't automatically send information between two departments.

Employees solved the problem by creating a spreadsheet. Every afternoon someone exported data from System A, cleaned it up, put it into the spreadsheet, and emailed it to another department. Someone in that department reviewed the spreadsheet and entered the information into System B.

Not ideal, but it worked.

After years of doing this, something interesting happens. The spreadsheet becomes part of the official process.

Documentation gets written around it. Employees are trained on it. Managers expect it. Maybe somebody even creates reports based on it.

Eventually the company replaces System A and System B with modern platforms that can communicate directly.

Now comes the critical question: What happens to the spreadsheet?

You would think the answer is obvious. Delete it.

But that's often not what happens.

Instead, someone adds a requirement to the new system: “We need it to generate the spreadsheet.”

Why? Because that's how we've always done it.

We have taken a workaround created because of a limitation in the old technology and turned it into a requirement for the new technology.

Requirements Need a “Why”

This is why I believe one of the most powerful questions in technology and Product Management is also one of the simplest: Why?

When someone says, “We need this report.” Why?

“We need this approval.” Why?

“We need this field.” Why?

“We need users to enter this information.” Why?

“We need the new system to work exactly like the old one.” Why?

This isn't about challenging people for the sake of challenging them. It's about understanding the business outcome behind the request.

If someone needs a report because they use three pieces of information from it to make a decision, maybe they don't actually need the report. They need those three pieces of information.

There may be a much better way to give it to them.

Don't Confuse Familiar With Good

There is also a very human element to this. People like what they know.

Even when an existing process is frustrating, employees understand it. They know its quirks. They know which buttons to push, which spreadsheets to open, and which shortcuts make it tolerable.

A new process introduces uncertainty.

So when organizations implement new technology, there can be tremendous pressure to make it behave like the system it's replacing.

That may make the transition easier, but it can also defeat much of the purpose of modernization.

Familiar doesn't necessarily mean efficient.

Sometimes the uncomfortable part of modernization isn't implementing the new technology. It's letting go of the old process.

Start With the Outcome

This connects directly to something I wrote about recently: Stop Automating Bad Processes.

Before automating something, understand what people are actually trying to accomplish. The same principle applies when replacing technology.

Don't start with: “How do we recreate what we have?”

Start with: “What are we trying to accomplish?”

Then work backward.

What information is actually required? What decisions need to be made? Who really needs to be involved? Which controls are necessary? Which steps exist only because of limitations in the old system? Which reports are actually being used? Which approvals add value? And which things are simply organizational habits?

Once you understand that, you can design the process first and choose how technology supports it second.

Modernization Isn't a Technology Project

This is where I think many modernization efforts get into trouble. They are treated primarily as technology projects.
Replace the database. Move to the cloud. Implement the SaaS platform. Rewrite the application. Build the APIs. Migrate the data.

All of those things may be necessary. But technology modernization without process modernization leaves a tremendous amount of value on the table.

If you move a bad process into the cloud, you still have a bad process.

If you rebuild an unnecessary workflow using modern APIs, it's still an unnecessary workflow.

If you use AI to automate a decision nobody needs to make anymore, you've simply created a very sophisticated way of wasting time.

New technology doesn't automatically create a better business. Better thinking does.

Before You Rebuild It, Challenge It

Whenever I look at an existing process, I like to mentally put every step into one of three buckets: Keep it. Simplify it. Eliminate it.

Some things absolutely need to remain. Some things still provide value but can be dramatically simplified. And some things exist only because they have always existed.

Those are the ones we need to be willing to eliminate.

That can be uncomfortable because eliminating a process often means questioning years of institutional knowledge. But that's exactly why modernization creates such a valuable opportunity.

You're already changing the technology. You're already disrupting the organization. You're already investing the time and money.

This is your chance to question everything surrounding it.

Otherwise, you may spend a great deal of money implementing tomorrow's technology only to recreate yesterday's business.

And that's not modernization.

That's just a newer way of doing the same old thing.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

The Difference Between Fixing a Problem and Fixing the Symptom

One of the easiest traps to fall into in IT and Product is confusing making a problem go away with actually solving the problem.

A production system goes down. Get it running.
A user can't complete a transaction. Find a workaround.
A database is slow. Add resources.
Customers keep opening the same support ticket. Give them the instructions again.

All of those can be perfectly reasonable responses, especially when something is broken and people are waiting. But there's an important difference between restoring service and solving the problem.

Restoration asks: How do we get things working again?
Resolution asks: Why did this happen, and what needs to change so we don't have to do this again?

When the Workaround Becomes the Process

Imagine an application that slows down every Monday morning.

Someone discovers that restarting a service fixes it. The restart takes five minutes, performance returns to normal, and everyone gets back to work.

Problem solved, right?

Not really.

Next Monday, someone restarts it again. Then again the following Monday. Six months later, the organization has developed an operational procedure around restarting something that shouldn't need restarting in the first place.

Eventually, someone says, "That's just what we have to do on Mondays."

That's when a workaround has quietly become part of the architecture.

The actual problem might be a memory leak, an inefficient database query, a scheduled process, a resource constraint, an integration issue, or something else entirely.

Restarting the service addresses the symptom. Understanding why the service needs to be restarted addresses the problem.

The Same Thing Happens With Support

Consider a support team receiving the same question from customers over and over again.

The immediate response might be to improve the documentation. And maybe that's the right answer.

But what if customers need the documentation because the application itself is confusing?

We can write better instructions explaining how to navigate a poorly designed process, or we can ask why the process is confusing in the first place.

Both approaches might reduce today's support burden. Only one potentially eliminates tomorrow's ticket.

A good fix closes a ticket. A great fix prevents the next ticket from ever being opened.

Product Teams Fall Into the Same Trap

The same thinking applies to Product decisions.

A customer asks for a feature. Then another customer asks for something similar. Soon the request appears on the roadmap.

But before building it, there's an important question worth asking:

What problem are customers actually trying to solve?

Sometimes the feature customers request is exactly what they need. Other times, the feature request is simply evidence of a deeper problem.

Maybe an existing workflow is too complicated. Maybe information isn't available when customers need it. Maybe two systems that should communicate don't. Maybe users have created a manual workaround because the original process no longer fits how the business operates.

Building the requested feature without understanding the underlying problem can create another layer of complexity without actually improving the experience.

Sometimes the feature a customer asks for isn't the solution. It's evidence of the problem.

Our Metrics Can Encourage the Wrong Behavior

There's another reason organizations fall into symptom-driven problem-solving: fixing symptoms produces immediate, measurable results.

"We closed 247 tickets this month."
"We reduced the backlog."
"We restored production in 12 minutes."
"We delivered the requested feature."

Those aren't bad accomplishments. But they measure activity more easily than they measure improvement.

Suppose the support organization handled 100 tickets for the same issue last year. This year, someone fixes the underlying problem and only 10 tickets are created.

Ticket volume went down.

From one perspective, the support team accomplished less. From another, the organization became dramatically better.

That's why leaders need to look beyond how quickly teams respond to problems and ask how often the same problems are coming back.

Restore First. Then Investigate.

None of this means every production incident should immediately turn into a lengthy Root Cause Analysis.

When production is down and customers can't work, the priority should be clear: Get them working again.

Restore the service. Implement the workaround. Get the business moving.

But once the immediate problem is under control, don't automatically consider the job finished.

Ask why it happened. Ask whether it has happened before. Ask what would prevent it from happening again. And perhaps most importantly, ask whether the organization has unknowingly built procedures around problems that should have been eliminated years ago.

Because there is a big difference between being good at fixing things and building systems that don't constantly need fixing.

Fix the symptom when you have to. Fix the problem so you don't have to again.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Your Engineering Team Is Busy. But Are They Moving the Product Forward?

There’s a strange thing that can happen inside a growing software organization.

Everyone is busy.

Developers have full backlogs. Product has more requests than it can prioritize. Support tickets keep coming. Meetings fill the calendar. Releases happen. Bugs get fixed. Customers get answers.

From the outside, the organization looks incredibly productive.

But then someone asks a deceptively simple question:

“What have we actually improved?”

And sometimes the answer is surprisingly difficult.

That’s because being busy and moving forward are not the same thing.

When 100% Capacity Produces Very Little Capacity

Most organizations want their people fully utilized. On paper, that makes sense. If you’re paying for an engineering team, why wouldn’t you want them working at capacity?

The problem is what happens when every available hour is already committed.

A production issue appears. Something moves.

A major customer escalates a request. Something else moves.

Sales needs functionality for an opportunity. Move something again.

A security issue needs attention. Another priority changes.

Pretty soon the roadmap isn’t really a roadmap anymore. It’s a constantly rearranging list of whatever is most urgent today.

The team may technically be at 100% utilization, but it has almost 0% flexibility.

And software organizations without flexibility eventually become reactive organizations.

Firefighting Feels Productive

There’s something deceptive about firefighting: it feels incredibly productive.

A critical issue comes in. People jump on a call. Developers investigate. Someone finds the problem. A fix gets deployed. Everyone celebrates.

Problem solved.

And they should. Solving production problems matters.

But if the same team spends week after week responding to emergencies, customer escalations, defects, and operational problems, something important is being crowded out.

The work that prevents tomorrow’s emergencies.

• Refactoring.
• Automation.
• Testing.
• Monitoring.
• Documentation.
• Architecture improvements.
• Developer tooling.
• Removing obsolete code.
• Simplifying complicated workflows.

None of those things usually arrive marked URGENT.

So they keep getting pushed to next sprint.

• Then next month.
• Then next quarter.

Eventually, “we’ll get to that later” becomes part of the architecture.

The Roadmap Slowly Changes

Healthy product roadmaps contain a balance of work.

There are customer capabilities, strategic investments, technical improvements, operational work, and sometimes experiments that may not produce immediate revenue but help determine where the product goes next.

• Reactive organizations gradually lose that balance.
• The roadmap becomes dominated by tactical work.
• What does Customer A need?
• What broke yesterday?
• What did Sales promise?
• What needs to ship before the next renewal?
• What problem is Support escalating?

All of those can be legitimate priorities.

But if everything is urgent, strategy eventually becomes whatever survives the interruptions.

That’s not really strategy.

It’s triage.

Deployment Anxiety Is a Warning Sign

Another symptom appears when teams become nervous about releasing software.

You hear things like:

• “Let’s wait until Monday.”
• “Who else needs to be online when we deploy this?”
• “Do we know what else this might affect?”
• Or my personal favorite:
• “Don’t touch that.”

Some caution around production systems is healthy. Nobody wants developers recklessly deploying changes.

But fear is different from discipline.

If routine changes require heroic coordination because nobody completely understands what might break, the organization has accumulated risk faster than it has accumulated confidence.

• Eventually that affects velocity.
• Changes get smaller.
• Release cycles get longer.
• Innovation slows.

And the organization begins protecting the existing system instead of improving it.

Your Best Developers Often Become the Bottleneck

There’s another pattern I’ve seen repeatedly.

As systems become more complicated, institutional knowledge concentrates around a handful of experienced people.

• Everyone knows who they are.
• When something strange happens, call Sarah.
• Before changing that module, ask John.
• Nobody deploys that service unless Mike is available.
• At first, those people look incredibly valuable — and they are.
• But the organization has also created a dangerous dependency.
• Your strongest engineers gradually become human routing tables for the platform.
• Instead of designing what comes next, they spend their time explaining what already exists.
• Instead of mentoring and improving architecture, they get pulled into every production problem.
• The better they are at solving emergencies, the more emergencies they receive.

Expertise becomes a bottleneck instead of a force multiplier.

New Developers Tell You More Than You Think

One of the best indicators of platform maturity is what happens when a new developer joins the team.

How long does it take before that person can safely make a meaningful contribution?

• A few days?
• A few weeks?
• Several months?
• Do they have documentation?
• Automated tests?
• Repeatable development environments?
• Clear architectural patterns?
• Or does onboarding consist mostly of someone saying:
• “Sit with me and I’ll explain how all of this works.”
• Complex systems naturally require time to learn. That isn’t necessarily a problem.
• But when knowledge exists primarily in people instead of systems, documentation, standards, and automation, growth becomes increasingly difficult.
• Every new developer requires more time from the developers who are already overloaded.

Now the very people you hired to increase capacity initially reduce capacity.

Modernization Cannot Be Leftover Work

This is where leadership has to make an intentional decision.

If modernization only happens when engineering “has some extra time,” it probably isn’t going to happen.

• There is always another feature.
• Another customer.
• Another bug.
• Another deadline.
• Another escalation.

Healthy organizations deliberately reserve engineering capacity for improving the platform itself.

That percentage doesn’t have to be the same for every company or every quarter. Sometimes business conditions legitimately require nearly everyone to focus on a major delivery.

But modernization needs to exist as a real priority rather than a hopeful future activity.

You cannot continuously withdraw from the technical health of a platform without eventually making deposits.

The Customer May Never See the Most Important Work

This can be difficult because some of the most valuable engineering work produces almost nothing visible to the customer.

• Customers don't necessarily see improved CI/CD pipelines.
• They don't see automated regression testing.
• They don't see refactored architecture.
• They don't see better observability.
• They don't see standardized development patterns.
• What they eventually see is the result.
• Fewer outages.
• Faster releases.
• More predictable delivery.
• Better performance.
• Fewer regressions.

And a product that can evolve without everyone holding their breath every time something changes.

That is why technical health is ultimately a product concern and a business concern, not simply an engineering concern.

Stop Measuring Productivity by How Full the Backlog Is

A full backlog doesn't tell me that an engineering organization is healthy.

• Neither does a calendar full of meetings.
• Neither does the number of tickets closed.
• Neither does having every developer allocated at 100%.
• Those things measure activity.
• Leadership needs to look beyond activity and ask whether the organization is actually increasing its ability to deliver.
• Are releases becoming easier or harder?
• Are developers spending more or less time firefighting?
• Is onboarding getting faster?
• Are recurring problems being eliminated or repeatedly fixed?
• How much engineering capacity goes toward innovation versus maintenance?
• Are we reducing complexity or simply learning to tolerate more of it?

Those questions tell us much more about the direction of the organization.

Leave Room to Move Forward

High-performing engineering organizations absolutely work hard.

• But they also create room to think.
• Room to improve.
• Room to automate.
• Room to refactor.
• Room to experiment.

And occasionally, room to question why something has been done the same way for the last ten years.

A team running at 100% capacity all the time isn't necessarily operating efficiently. It may simply have no room left to become more efficient.

The goal shouldn't be to keep engineering as busy as possible.

The goal should be to create an engineering organization capable of continuously delivering value while making the platform easier — not harder — to change tomorrow.

Because ultimately, the question isn't:

“Is everyone busy?”

It's:

“Are we moving the product forward?”

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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