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/

 

Stop Automating Bad Processes

There is a phrase I have heard throughout my career: “We need to automate this.”

Sometimes we do. But before we start talking about APIs, AI, workflow engines, integrations, databases, or writing a single line of code, I think there is a much more important question: Should we be doing this process at all?

Because automating a bad process doesn't make it a good process. It just makes the bad process run faster.

Technology Shouldn't Be the First Question

One of the mistakes I've seen organizations make repeatedly is starting with the technology. Someone identifies a manual process and immediately the conversation becomes: Can we automate this?

My first questions are usually different: Why are we doing this? What decision is the person actually making? What information do they need to make that decision? What happens before and after that decision? And perhaps most importantly, does this process still make sense?

Processes have a funny way of surviving long after the reason they were created has disappeared. Someone created a spreadsheet ten years ago. Someone else added another approval. A new regulation added another step. A manager wanted another report. A system couldn't do something, so employees invented a workaround.

Years later, nobody remembers exactly why the process works the way it does. They just know: “That's how we've always done it.”

Then somebody comes along and says: “Let's automate it.”

That is exactly when we should be careful.

A Lesson From Claims Assignment

Earlier in my career, I worked with claims-assignment processes. On the surface, the problem seemed straightforward. A claim came into the organization and someone needed to determine who should receive it.

There were rules, territories, workloads, different types of claims, and people making decisions based on all of those factors.

The easy technology answer would have been to simply reproduce what those people were already doing in software. But that wasn't really the problem we needed to solve.

The important part was understanding how the decision was actually being made. What information mattered? Which rules were real requirements? Which were simply habits? Which exceptions actually mattered? What judgment were people applying?

Once you understand those things, something interesting happens. You stop thinking about how to automate the existing steps and start thinking about how to achieve the outcome.

That's a very different problem.

Minutes, Hours...Then Seconds

The existing assignment process could take minutes of someone's actual working time, but the elapsed time could be much longer.

A claim might arrive and wait for someone to review it. That person might need additional information. They had other work ahead of it. They might be at lunch, in a meeting, helping another customer, or gone for the day.

A process requiring only a few minutes of human effort could therefore take considerably longer before the assignment actually occurred.

When we redesigned that process around the decision instead of simply reproducing the manual workflow, the assignment could happen in seconds.

That distinction is important. We didn't make someone click through the same process faster. We removed the need for most of the process.

That is where the real value of automation comes from.

Don't Automate the Clicks

This becomes even more important today because automation is becoming incredibly easy. With AI, low-code platforms, APIs, robotic process automation, and modern SaaS tools, organizations can automate processes faster than ever before.

That's wonderful. It is also dangerous, because we can now automate bad ideas faster than ever before.

Imagine an employee receives an email, downloads an attachment, opens a spreadsheet, looks up information in another system, copies several values into the spreadsheet, determines a category, emails the spreadsheet to another person, and then that person enters the information into yet another system.

You could absolutely automate all of those steps.

But perhaps the better question is: Why are there so many steps in the first place?

Maybe the information already exists. Maybe the spreadsheet shouldn't exist. Maybe the second person doesn't need to be involved. Maybe the category can be determined when the original transaction occurs. Maybe the systems should communicate directly.

Maybe most of the process can simply disappear.

That is process improvement. Automation comes afterward.

Talk to the People Doing the Work

There is another lesson here that technology teams sometimes forget: The people doing the work usually know where the problems are.

They know which screens waste their time. They know which approvals accomplish nothing. They know which spreadsheet exists because two systems don't communicate. They know which information they enter twice. They know which rules don't make sense in the real world.

If you walk into that environment with a predetermined technology solution, you will probably miss much of that knowledge.

Instead, sit with them. Watch the process. Ask why. Then ask why again.

You may discover that what management believes the process looks like and what actually happens every day are two very different things. That difference is often where the biggest opportunities live.

AI Makes This More Important, Not Less

Today, every organization is asking where AI fits. That's a reasonable question, but I think we should resist the temptation to sprinkle AI across every existing business process simply because we can.

Before asking “How can AI automate this?”, ask “What are we actually trying to accomplish?”

Then ask: “What is the simplest way to accomplish it?”

Sometimes the answer will be AI. Sometimes it will be traditional automation. Sometimes it will be an integration between two systems. Sometimes it will be changing a business rule.

And occasionally, the best technology solution will be: Delete the process entirely.

Automation Is a Multiplier

This is the principle I keep coming back to: Automation is a multiplier.

Give automation a well-designed process and it can multiply productivity, consistency, speed, and scale. Give automation a poorly designed process and it can multiply complexity, mistakes, technical debt, and cost.

So before building the workflow, buying another platform, creating another integration, or telling the AI to automate everything, spend some time understanding the work.

Talk to the people doing it. Understand the decisions being made. Challenge the assumptions behind the process. Remove the steps that don't need to exist. Simplify what remains.

Then automate it.

Because the goal isn't to automate more work.

The goal is to need less work in the first place.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

When Does Customer Service Start Breaking Your SaaS Product?

One of the easiest things for a software company to say is “Yes, we can do that.”

A good customer asks for a feature. Sales wants to close an important deal. An existing client has a workflow that’s just a little different from everyone else’s. The request makes its way to Product and Engineering, everyone talks it through, and eventually someone says, “It’s not ideal, but we can make it work.”

So we do. And in isolation, that decision may make perfect sense. The problem usually isn’t that decision. It’s the next 50 decisions just like it.

Customer Focus Is a Good Thing

I want to be clear about something upfront: listening to customers is not the problem. Great products are built by understanding the people who actually use them. Some of the best product ideas I’ve encountered didn’t originate in a conference room. They came from customers doing real work and discovering something the software didn’t handle particularly well.

That feedback is invaluable. But there is an important difference between learning from customers and building a different product for every customer. Those two things can look surprisingly similar in the beginning, but over time they lead to very different places.

“Just This Once”

Imagine Customer A needs a slightly different workflow, so we add an exception. Customer B needs a different approval process, so we add another. Customer C has a special reporting requirement. Customer D wants a field to behave differently. We can handle all of those.

Pretty soon, however, the platform starts accumulating logic that effectively says: If Customer A, do this. If Customer B, do that. Unless Feature X is enabled. Except when Workflow Y applies. But only when they’re using Integration Z.

At some point, you’re no longer developing a platform. You’re maintaining a collection of exceptions.

And nobody intentionally designed it that way. It happened one perfectly reasonable decision at a time.

Sales Probably Isn’t Trying to Break the Product

This is where these conversations sometimes become unnecessarily adversarial. Engineering blames Sales. Sales blames Product. Product blames Engineering. Support blames everyone.

That usually isn’t particularly helpful. Sales is trying to win business. Product is trying to satisfy customers. Engineering is trying to deliver what the business needs. Support is trying to keep customers happy. Everyone may be doing exactly what the organization has asked them to do.

The real problem is that nobody owns the cumulative effect of all those individual decisions. That’s a governance problem, not a people problem.

Customization Has a Compounding Cost

The first customer-specific feature might be inexpensive. The second probably is too. But every exception creates another path through the system, and that path has to be understood, tested, supported, documented, maintained, and considered every time something else changes.

This is where the economics become deceptive. A customization that takes a developer two days to build does not necessarily cost the company two days. The organization might have to support that decision for the next ten years.

Every future developer touching that area now has another condition to understand. Every QA cycle has another scenario to validate. Every production issue has another possible cause. Every architectural decision has another dependency.

The cost isn’t just building the exception. It’s carrying it.

Eventually, Everyone Becomes Afraid to Change Things

This is one of the clearest signs that customization has gotten out of control. A developer proposes changing something fundamental, and somebody asks:

“Do we know which customers depend on this?”

Someone thinks Customer X uses it. Someone else remembers Customer Y had something similar three years ago. Nobody is completely certain.

So the safest decision becomes: Don’t change it.

That’s how innovation starts slowing down. Not because the developers aren’t capable. Not because Product doesn’t have ideas. Not because leadership stopped caring. The organization has simply accumulated so many exceptions that the cost of understanding change has become greater than the perceived benefit of making it.

Configuration Is Different

Mature platforms eventually learn an important lesson: customers need flexibility, but flexibility doesn’t always require custom code.

That’s where configuration becomes incredibly powerful. Instead of saying, “We’ll modify the application for your workflow,” the conversation becomes, “How can we make the workflow configurable?”

Instead of building five customer-specific versions of something, we build one capability with well-defined options. That might mean feature flags, rules engines, configurable workflows, templates, permissions, business rules, APIs, metadata, or something entirely different depending on the product.

The exact implementation isn’t the important part. The principle is: move variation out of custom code and into intentional platform capabilities whenever practical.

The customer still gets flexibility, but the platform remains a platform.

Sometimes You Should Still Say Yes

None of this means every customer-specific request should be rejected. Business isn’t that simple. A major customer may have a legitimate requirement that justifies customization. A regulatory requirement may demand it. A strategic customer might expose a use case that eventually benefits the entire market.

Sometimes the correct business decision absolutely is “Yes. Build it.”

But that decision should be intentional. The organization should understand whether it is creating a product capability or a customer exception. Those aren’t necessarily the same investment.

Product Governance Matters

This is why healthy SaaS organizations need strong product and technical governance. Someone needs to ask questions beyond “Can we build this?”

Of course we can build it. That’s rarely the interesting question.

The better questions are: Should we build it? Is this solving a customer problem or one customer’s implementation problem? Will other customers benefit from it? Can it become a configurable capability instead of custom logic? What long-term support obligation are we creating? Does this move the platform forward, or make it harder to move forward later?

Those conversations aren’t bureaucracy. They’re how you protect the future of the product.

The Customer Who Pays for the Feature Isn’t the Only Customer Paying for It

This may be the most important part. When excessive customization makes a platform harder to maintain, every customer eventually pays.

They pay through slower releases, more bugs, longer support cycles, and new capabilities that take increasingly longer to develop. Eventually, the organization accumulates so much complexity that somebody walks into a meeting and says:

“We need to rewrite this thing.”

Sound familiar?

Build a Platform, Not a Collection of Exceptions

A mature product organization doesn’t stop listening to customers. It gets better at listening.

Instead of asking only, “What does this customer want us to build?” it starts asking:

“What is this customer teaching us about what the platform needs to become?”

That is a very different conversation. One produces another customization. The other produces product strategy.

Over enough years, that distinction can determine whether you’re building a scalable SaaS platform — or maintaining hundreds of customer-specific exceptions held together by increasingly nervous developers.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Your SaaS Platform Probably Doesn't Need a Rewrite. It Needs to Grow Up.

 

There is a moment in the life of many successful software products when someone finally says it: "We need to rewrite this thing."

 

The developers are frustrated. Releases are getting harder. Bugs seem to appear in places nobody expected. Customers have workflows nobody completely understands anymore. There are integrations nobody wants to touch.

 

Someone inevitably looks at the old platform and says:

• "If we could just start over..."
• I've seen this story before.
• And sometimes a rewrite really is necessary.
• But quite often, the technology isn't the real problem.

The organization has simply outgrown the way it builds and manages software.

 

Success Creates Its Own Technical Debt

We normally talk about technical debt as though someone did something wrong.

 

That's not always fair.

 

Some technical debt is simply the cost of moving quickly. 

 

A company gets a new customer who needs something immediately. A developer creates a workaround. Sales lands another major customer with slightly different requirements. Another exception gets added.

 

• The company grows.
• Revenue grows.
• The platform grows.
• And everyone celebrates as they should.
• But something else has been growing quietly in the background.

Complexity.

 

• The temporary workaround becomes permanent.
• The exception becomes a feature.
• The feature gets another exception.

Before long, nobody remembers exactly why certain things work the way they do. They just know changing them might break something.

 

That's when healthy growth debt can begin turning into dangerous operational debt.

 

The Financial Statements May Not Warn You

 

This is where things become particularly interesting from a leadership perspective.

 

• A software company can look financially healthy while its technology platform is becoming increasingly unhealthy.
• Revenue may still be growing.
• EBITDA may look good.
• Customer churn may remain low.
• Yet inside the organization, something very different is happening.
• Release cycles are getting longer.
• Developers are becoming increasingly cautious about deployments.
• More engineering capacity is spent fixing problems instead of creating capabilities.
• Customer-specific workarounds multiply.
• New developers take longer to become productive.

And the product roadmap gradually changes from:

 

• What should we build next?

to:

• What can we safely change without breaking something?

 

Those are two very different companies.

 

Low churn doesn't necessarily mean customers love your product, either. Sometimes customers remain because switching platforms is difficult, expensive, or disruptive.

Stable revenue can hide an enormous amount of operational fragility.

 

The Most Dangerous Phrase May Be "Don't Touch That"

 

Several warning signs show a platform drifting from innovation into maintenance mode.

• One of my favorites is deployment anxiety.
• Everyone knows that part of the system.
• Maybe only one developer understands it.
• Maybe nobody completely understands it.
• Eventually the institutional knowledge becomes:  Don't touch that unless you absolutely must.

That's not just technical debt anymore.   That's organizational risk.

Another warning sign is constant firefighting.

1. Engineering teams become extremely busy while accomplishing surprisingly little strategic work.
2. Everyone is working.
3. Everyone is solving problems.
4. Everyone is exhausted.
5. But the platform isn't really moving forward.

Activity and progress aren't the same thing.

 

Then Someone Suggests the Rewrite

• At this point, a complete rewrite starts sounding incredibly attractive.
• New architecture.
• New framework.
• Clean database.
• Modern APIs.
• No legacy code.
• No ugly compromises.
• A fresh start.

I understand the appeal.

 

The problem is that your old application contains something incredibly valuable that rarely appears in an architecture diagram:  years of accumulated business knowledge.

 

• Every strange conditional statement may exist because five years ago a customer discovered an edge case.
• Every unusual workflow may represent a business requirement somebody forgot to document.
• Every integration may contain lessons learned through years of production failures and fixes.
• That ugly old platform isn't merely code.
• It is institutional memory expressed in software.
• When you rewrite it, you aren't simply replacing technology.
• You're attempting to rediscover years, sometimes decades, of business knowledge.
• And while you're doing that, you still have customers using the old system.
• Now you have two platforms to maintain.

Meanwhile, feature development slows because your best people are rebuilding capabilities customers already have.

 

That's an expensive way to discover that the old software wasn't the only problem.

 

You Can't Rewrite an Organizational Problem

 

This is the part I believe technology and business leaders sometimes overlook.

 

Suppose the original platform suffered from:

• weak product governance,
• constantly changing priorities,
• inadequate QA,
• unclear architectural ownership,
• customer-specific customization,
• interrupt-driven development, and
• no dedicated capacity for modernization.
  
  

Now imagine building a brand-new platform...     

using the same organization and processes.

• Question: What do we think is going to happen?
• Answer:  Eventually you'll have a beautiful new codebase carrying many of the same problems as the old one.

Because you replaced the technology without changing the system that produced it.

 

A rewrite is not automatically a transformation.

 

Mature Platforms Evolve

 

The alternative isn't ignoring technical debt.  Quite the opposite.

• Healthy technology organizations treat modernization as part of operating the business.
• They continuously refactor high-risk areas.
• They automate testing and deployment.
• They establish architectural standards.
• They create clear ownership.
• They invest in observability.
• And perhaps most importantly, they resist solving every customer's problem with another piece of custom code.
• Whenever possible, mature platforms become configurable rather than customized.
• That's a subtle distinction with enormous consequences.
• Customization says: We'll change the software for you.
• Configuration says: We designed the platform so it can adapt to you.

One scales.  The other eventually becomes a collection of exceptions pretending to be a product.

 

Engineering Needs Room to Improve the Engine

 

There is also an uncomfortable economic reality here.

 

If 100% of engineering capacity is allocated to customer requests, features, and production problems, then effectively 0% is being invested in the future health of the platform.

 

Eventually, that bill comes due.

 

Organizations need intentional modernization capacity.

• Not someday.
• Not "when things slow down."
• Because things rarely slow down.

Technical leadership must deliberately balance innovation, stability, and modernization.

 

That means sometimes saying:  "We're going to spend engineering capacity improving something the customer may never directly see."

 

• Better deployment pipelines.
• Automated testing.
• Architecture improvements.
• Monitoring.
• Refactoring.
• Standardization.

Those things aren't distractions from product development.

 

They are what make continued product development possible.

 

Technical Debt Eventually Becomes Financial Debt

 

This is where the technology conversation becomes a business conversation.

 

Technical debt doesn't remain technical forever.

 

Eventually, it appears somewhere on the financial side of the organization.

 

• Higher support costs.
• Longer development cycles.
• More engineers required to deliver the same amount of functionality.
• Slower customer onboarding.
• Increasing infrastructure costs.
• Reduced innovation.
• Missed opportunities.
• Margin compression.

Eventually, the company realizes it isn't simply maintaining software.

 

• It's paying interest on years of deferred decisions.
• The Question Leaders Should Be Asking

So instead of immediately asking: "Should we rewrite the platform?"

 

I think leadership teams should start with several different questions. 

 

1. What operational risks are currently hidden beneath stable revenue?
2. Are we scaling our architecture or simply scaling our workarounds?
3. How much engineering capacity is going toward innovation versus maintenance?
4. Are we building a platform, or are we maintaining hundreds of customer-specific exceptions?

And perhaps the most important question: If we built the entire platform again tomorrow but kept the same leadership structure, priorities, processes, and engineering practices, would we eventually end up right back where we are today?

 

If the answer is yes, the problem probably isn't the codebase.

 

Technology platforms don't become sustainable because they're new.

 

They become sustainable because the organizations responsible for them develop the discipline to continuously evolve them.

 

The goal shouldn't be to build software that never becomes old.  That's impossible.

 

The goal is to build an organization capable of helping its technology grow old gracefully while continuously making it better.

 

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

From Personal Habit to Team Habit: Getting Your Team to Build an AI Toolbox

A few weeks ago I wrote about building a personal AI toolbox — using Claude, ChatGPT, and GitHub Copilot for different stages of work instead of arguing over which one is "best." That post landed with a lot of people individually. But it also surfaced a question I didn't expect: okay, but how do I get my team to actually work this way?

 

That's a harder problem than it sounds, and it's worth separating from the personal version.

 

Why "just use AI" doesn't work as team guidance

Most teams I've seen approach AI adoption the same way they approach a new tool rollout: pick one platform, license it, tell everyone to use it. That works fine for something like a ticketing system, where the whole point is that everyone uses the same one.

 

It doesn't work for AI, because — as I wrote last time — different tools genuinely do different jobs well. Standardizing on a single platform for a team doesn't eliminate the "which tool for which job" problem. It just hides it, because now everyone is quietly using the wrong tool for at least some of their work, and nobody's saying so out loud.

 

The result is usually one of two failure modes: people quietly stop using the mandated tool for the tasks it's bad at, or they force it to work anyway and produce mediocre output while telling themselves "well, that's just what AI does."

 

What actually changes at the team level

The individual "routing" skill I described last time — knowing which tool fits which stage of work — still matters. But at the team level, three additional things become the real work:

1. Shared vocabulary for the stages. If I say "let's ChatGPT this" and my teammate says "let's Claude this," we're actually agreeing on something useful — that this is early-stage shaping work versus deep project work — even if it sounds like we're just naming brands. Getting a team to name the stages of work, not just the tools, is what makes routing something you can talk about instead of something everyone does silently and differently.
2. Permission to use more than one tool. This sounds obvious, but it's the single biggest blocker I've seen. Procurement and IT naturally want to minimize the number of licensed tools, for good reasons — cost, security review, support burden. But if a team is only allowed one AI platform, you've reintroduced the exact problem the personal toolbox approach was meant to solve. Part of the leadership job here is making the case that two or three well-chosen tools, used deliberately, produce better outcomes than one tool used for everything.
3. Visibility into how people are actually using each tool. Not surveillance — just enough shared practice that the team learns from each other. If one engineer has figured out that Copilot handles a particular kind of refactor well, and another is fighting through the same kind of refactor manually, that's a five-minute conversation that saves real time. Most teams have no mechanism for this kind of exchange because "how I use AI" isn't normally treated as something worth discussing out loud.

What this looks like in practice

On my own team, the shift wasn't a policy — it was a habit. We started naming, casually, which "mode" a task was in before jumping into a tool. Is this a strategy conversation, or is this project work? Is this something that needs deep context, or is it a quick inline assist? Once that became a normal question to ask out loud, people naturally reached for different tools without needing a mandate.

 

The other change was simply normalizing "I used two tools for this." Early on, there was a faint sense that switching tools mid-task meant you'd picked wrong the first time. Once that stigma went away — once "I sparred with ChatGPT on the approach, then built it out in Claude" became a completely unremarkable thing to say in a standup — the whole team's AI use got noticeably more effective.

 

The leadership takeaway

If you're leading a team through AI adoption, the temptation is to simplify the decision for people: pick one tool, roll it out, move on. I understand the appeal. But the simplification is actually removing the thing that makes AI valuable in the first place — the ability to match a fluid, capable tool to the actual shape of the work in front of you.

 

The job isn't to pick the tool for your team. It's to build a team that knows how to pick.

 

#ArtificialIntelligence #ChatGPT #ClaudeAI #GitHubCopilot #Leadership #SoftwareDevelopment #Technology

 

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Building Your AI Toolbox: A Practical Guide to Using Claude, ChatGPT, and Copilot Together

Earlier this month I made the case that comparing AI platforms head-to-head misses the point. The question I keep seeing — "which AI is better?" — isn't really the question that matters. What matters is which tool fits the job in front of you.

That post seemed to resonate with people, so I want to go one step further. Because knowing that you should have an AI toolbox doesn't help much if you don't actually know how to use one. Owning a toolbox and knowing your workflow are two different things.

So here's what my workflow actually looks like, tool by tool, and the thinking behind it.

The problem with picking a "favorite"

Most of the AI discourse I see online is framed as a competition. Someone posts a benchmark, someone else posts a counter-example, and the comments turn into a debate about which platform "wins." I understand the impulse — we like rankings, they're easy to argue about, and picking a favorite feels like it saves you the work of thinking further.

But the ranking impulse breaks down the moment you actually try to use these tools for real work. A tool that's excellent at one stage of a task can be mediocre at another stage of the same task. If you judge it only on the stage where it's weak, you conclude "this AI isn't very good," when really you just used a screwdriver to turn a bolt.

The fix isn't finding the one tool that's good at everything. It's noticing that your work itself has stages, and matching the tool to the stage.

The three stages of a piece of work

When I look back at how I actually get things done, three distinct modes show up over and over:

1. Shaping the problem. This is the messy, early part — before you know exactly what you're building, sometimes before you're even sure the idea is a good one. You need something to push back on you, ask the annoying follow-up question, and help you find the holes in your own thinking.

2. Doing the real work. Once the idea is solid enough to act on, the job changes completely. Now you need depth and continuity — something that can hold the whole shape of a project, a codebase, or a document, not just one clever exchange.

3. Executing in the flow. This is the moment-to-moment part — writing the actual code, making the actual edit — where you don't want a conversation at all. You want something quietly keeping pace with you.

Three different jobs. Three different tools, for me.

How I actually use each one

ChatGPT, for shaping the problem. Before I write a line of code or open a document, I want to know I'm solving the right problem in the first place. I'll bring ChatGPT a half-formed idea — a technical approach, a leadership challenge, a strategy question — and use the back-and-forth to stress-test it. It's less "give me the answer" and more "help me find out where I'm wrong." That adversarial, sparring-partner quality is what makes it useful here. I'm not looking for agreement; I'm looking for friction.

Claude, for the real work. Once an idea turns into actual work — a project, a codebase, a document that needs real structure — that's when Claude takes over for me. It holds context across a whole piece of work rather than a single exchange, and that matters enormously once you've moved past brainstorming and into building something that has to hang together. Give it a technical problem or a messy codebase and it can work through it methodically rather than needing to be re-oriented every few minutes.

GitHub Copilot, for the flow. Copilot doesn't get a dedicated "session" the way the other two do. It's just there, inline, while I'm actually writing code — finishing a line, suggesting the next one, staying out of the way otherwise. It's less a tool I deliberately reach for and more a tool that's already in my hand when I need it.

The skill isn't prompting — it's routing

Here's the pattern underneath all of this: the tool changes as the work changes. Early-stage thinking, deep project work, and in-the-moment execution are three different modes, and trying to force one AI to do all three is where people get frustrated and conclude "AI isn't that useful for X."

It's not that the AI failed. It's that it was doing a job it wasn't built for.

I think this is where a lot of the "prompt engineering" conversation misses the bigger picture. Getting better at prompting one tool only gets you so far if you're using the wrong tool for the stage of work you're in. The more valuable skill — the one that's actually going to compound over time — is routing: recognizing what stage of work you're in and knowing which tool matches it, before you even open the app.

A rough framework, if you want one

If it helps to have something concrete, here's roughly how I decide:

• Am I not sure what I'm building yet? → Start with a sparring partner. Push on the idea until it either survives or falls apart.
• Do I know what I'm building, and does it require holding a lot of context across a real project? → Move to a tool built for depth and continuity.
• Am I already doing the work, and just need help keeping pace? → Use whatever lives inline, in the flow, with the least friction.

It's not a rigid rule, and there's plenty of overlap — any of these tools can do a decent job outside its "home" stage. But defaulting to this kind of routing has made my own work noticeably less frustrating, because I'm no longer expecting one tool to be everything at once.

The real competitive advantage

The future of AI probably isn't about picking one AI platform and becoming an expert in it. It's about building a toolbox and learning, almost instinctively, which tool to reach for depending on the job in front of you.

The real competitive advantage may not be having access to AI — at this point, most people do. It may be knowing which AI to use, when to use it, and how to move between them without losing momentum.

That's the part I'm still refining. But it's already changed how I work.

#ArtificialIntelligence #ChatGPT #ClaudeAI #GitHubCopilot #Leadership #SoftwareDevelopment #Technology

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

 

Building Your AI Toolbox: Why I Use Claude, ChatGPT, and GitHub Copilot Differently

There seems to be a constant debate happening around artificial intelligence: Which AI platform is the best?

Is it ChatGPT? Claude? GitHub Copilot? Something else?

I think we may be asking the wrong question.

I have spent most of my career working with technology, and one thing technology teaches you very quickly is that there is rarely one tool that is best at everything.

Think about the toolbox you have at home. You probably have screwdrivers, wrenches, sockets, pliers, hammers, drills, and dozens of other tools. Nobody opens that toolbox and asks, "Which one of these is the best tool?"

The answer would be obvious: It depends on what you're trying to accomplish.

I believe we should start thinking about AI the same way.

AI Is Becoming a Toolbox

Over time, I have found myself using Claude, ChatGPT, and GitHub Copilot differently.

There is certainly overlap between them. All three continue to evolve, and each can perform tasks that might traditionally be associated with another platform. But that doesn't mean they feel the same when you're actually working with them.

Each has developed strengths that make me reach for it in different situations.

Claude: When I Want to Build

Claude has become particularly interesting to me when it comes to software development.

When I have a coding project, existing codebase, technical problem, or something that needs to be built and iterated upon, Claude can be an extremely capable development partner.

What I find valuable isn't simply its ability to generate code. Writing code is only one part of software development.

Understanding an existing application, following dependencies, recognizing patterns, making changes without unnecessarily disturbing other parts of the system, troubleshooting problems, and iterating on a solution are often much more important.

That makes Claude interesting as more than a code generator. It can become part of the development environment itself.

For someone who understands technology but may not necessarily spend every day writing code, tools like this can also dramatically reduce the distance between having an idea and actually building something.

GitHub Copilot: AI Where Developers Already Work

GitHub Copilot approaches the problem from another direction. Instead of asking developers to leave their normal workflow and go somewhere else to interact with AI, Copilot brings AI directly into the development process.

That is an important distinction.

Developers already spend their days inside editors, repositories, pull requests, and development tools. Having AI available inside that environment makes it a natural companion.

It can assist with writing code, understanding unfamiliar code, generating tests, explaining functions, suggesting improvements, and handling some of the repetitive work developers deal with every day.

The value isn't necessarily replacing the developer. It's reducing friction.

A good power tool doesn't replace the carpenter. It allows the carpenter to accomplish more with the skills and experience they already have.

I see Copilot in much the same way.

ChatGPT: My Sparring Partner

My relationship with ChatGPT is somewhat different.

I certainly use ChatGPT for technical questions and coding. It is more than capable of helping in those areas. But where I personally find it particularly valuable is as a sparring partner for ideas.

Sometimes I don't need someone to give me an answer. I need something that helps me think.

I may start with a business problem, a technical strategy, a leadership challenge, an architecture decision, a product idea, or simply a half-formed thought. Then I start asking questions:

What am I missing? What assumptions am I making? What happens if we approach this differently? What are the risks? How would I explain this to an executive? How would I explain the same thing to an engineer? What would someone who disagrees with me say?

Those conversations can be incredibly valuable.

For me, ChatGPT becomes less of an answer engine and more of a thinking environment.

The AI doesn't have to make the decision. I still make the decision. But having something available that can challenge an idea, organize my thoughts, explore alternatives, and help turn a rough concept into something actionable can dramatically accelerate the thinking process.

The Tools Are Starting to Overlap

There is an important caveat to all of this: These categories are not permanent.

Claude can absolutely help with strategy and writing. ChatGPT can absolutely build and troubleshoot software. GitHub Copilot continues expanding beyond simple code completion.

The boundaries between these platforms will continue to move. Six months from now, I may use them differently than I do today.

And that's actually part of the point.

We shouldn't become so attached to a particular AI platform that we stop evaluating the tools available to us.

Technology changes. Our toolbox should change with it.

The Bigger Skill Is Knowing Which Tool to Use

For years, organizations have focused on teaching people individual technologies: learn this programming language, learn this database, learn this project management platform, learn this cloud environment.

Those skills still matter. But AI introduces another skill that I think will become increasingly important:

Tool selection.

The most effective AI users may not be the people who know the most prompts or subscribe to the most AI platforms. They may simply be the people who understand their problem well enough to choose the right tool for it.

Sometimes that might mean Claude. Sometimes GitHub Copilot. Sometimes ChatGPT.

And sometimes the best answer might be using all three during different stages of the same project.

Imagine starting with ChatGPT to challenge an idea and develop the requirements. Then moving into Claude to explore the implementation and work through the codebase. Then using GitHub Copilot alongside the development team as the solution is written, tested, reviewed, and maintained.

That isn't three competing AI platforms. That's a toolchain.

AI Doesn't Replace Experience. It Amplifies It.

There is another part of this conversation that I think sometimes gets lost.

AI can generate an impressive amount of information very quickly. But speed isn't the same thing as judgment.

Someone still has to recognize when an answer doesn't make sense. Someone still has to understand the business. Someone still has to recognize technical risk. Someone still has to understand customers, employees, budgets, deadlines, security, and all the other constraints that exist in the real world.

Experience provides that context.

AI can dramatically accelerate what an experienced person is capable of doing, but the person still needs to know where they're going.

A power tool in experienced hands can accomplish remarkable things. The same tool in inexperienced hands can create a remarkable mess.

AI isn't much different.

Stop Looking for the Winner

I don't believe there needs to be a winner between Claude, ChatGPT, GitHub Copilot, or whatever platform comes next.

Competition between these companies will continue, and that's a good thing. It will make the tools better. But as users, we don't have to participate in the rivalry.

We can simply use the best tool available for the job in front of us.

The screwdriver doesn't need to defeat the hammer. The socket wrench doesn't need to replace the drill. They simply need to be there when we need them.

That is how I increasingly think about artificial intelligence.

Build your AI toolbox. Learn what each tool does well. Understand where each one struggles. Experiment with how they work together.

And most importantly, don't become so focused on finding the "best AI" that you miss the larger opportunity.

The advantage isn't necessarily having access to artificial intelligence anymore. More and more people already have that.

The advantage will be knowing which tool to reach for, when to reach for it, and having the experience and judgment to know what to do with the result.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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