The Power of YES: Finding a Way Forward

Most of us would enjoy sleeping a little later, spending more time on the couch, or having a few less things demanding our attention. I certainly understand the appeal. But there is also something rewarding about reaching the end of a difficult day and knowing you worked through something you could have easily put off.

That is what comes to mind when I think about the power of “yes.” Yes, I can take the next step. Yes, I can learn something new. Yes, this is difficult, but I am willing to work through it. That willingness gives us a place to begin, even when we do not have the whole answer.

In technology, product development, and leadership, challenges are part of the work. A customer needs something we have never built before. A solution that looked promising does not work as expected. A project takes a turn nobody anticipated. Those moments test our patience, but they also give us opportunities to improve how we think, communicate, and solve problems.

I appreciate people who can look at a difficult situation and say, “Let’s see how we can make this work.” They might ask questions, bring someone else into the conversation, or suggest a smaller first step. Their attitude helps the team get moving. Sometimes that is exactly what everyone needs.

Saying yes still requires good judgment. We have to be honest about our time, resources, and commitments. A responsible yes might sound like, “We can do that, but we need to adjust the timeline,” or, “Let’s start here and learn before we go further.” That kind of answer gives people a practical path forward and sets them up to succeed.

People who consistently make progress develop the habit of working through challenges. Sometimes they work harder. Often, they find a smarter approach. They ask for help, learn from an unsuccessful attempt, and make adjustments. There is strength in being willing to say, “My first approach did not work. What can I try next?”

Good leadership helps that attitude grow. When someone brings us a problem, our response matters. Listening carefully, asking useful questions, and helping remove an obstacle can give that person the confidence to keep going. Over time, those everyday interactions build a team that trusts its ability to handle difficult work together.

Many challenges turn out to be speed bumps. They slow us down, make us pay attention, and sometimes remind us to change our approach. Others require a longer detour or a different plan. We get better at recognizing the difference through experience and by being willing to learn along the way.

And yes, rest belongs in that picture too. We all need time to recharge and enjoy what we are working for. Progress becomes more sustainable when we take care of ourselves and return with the energy to give our best.

As we head into the weekend, think about something you have been putting off because it feels difficult or unfamiliar. You may not be able to finish it today, but perhaps you can ask the question, make the call, or take that first step.

Give yourself a chance to discover what you can do. A thoughtful “yes” today could be the beginning of something you will be proud of tomorrow.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Before You Add More Work, Ask What Can Come Off

Most teams can tell you what has been added to their workload over the past year. New reports, new meetings, another approval, or an extra step somebody requested along the way. Ask what has been removed, though, and the answer may take a little longer. We are usually much better at adding work than retiring it.

That connects to something I wrote about recently: your team may already know what needs to change. Listening to them is a good start, but we also have to give them room to act on what they know. If every improvement must fit around an already full day, even a useful idea can sit untouched for months. The people who understand the problem are still busy keeping everything moving.

Consider a weekly report that takes an hour to prepare. It may have started for a good reason, perhaps to monitor a difficult rollout or give someone information they couldn't get elsewhere. Years later, the report is still being produced, even though the rollout is finished and the information is available in another system. Somebody continues doing the work because nobody has decided it can stop.

I think this is an important part of leadership across product, development, operations, and the business. We spend a lot of time discussing what our teams should deliver next. We should also understand what they are carrying forward from earlier decisions. Otherwise, a new priority becomes another obligation on top of everything that was already a priority.

That does not mean every old process needs to go. Experience has taught me to respect the history behind how things work. An approval may protect a customer, a review may catch an expensive mistake, and a report may support a decision we do not see from our part of the business. Before removing something, we need to understand who depends on it and what purpose it still serves.

But respecting that history also means being willing to review it. Is the information still being used? Does the same person still need to approve this? Could we meet the original need with less effort? Those are reasonable questions, and the people doing the work should have a place in answering them.

There is an opportunity here for technology teams to deliver real value. Sometimes that means building a better product or improving an integration. Sometimes it means helping the business recognize that a task no longer needs to happen at all. Both require us to understand the work before deciding what to change.

A practical place to start is with one task. Ask your team what they would review first if the goal were to give them a little time back each week. Pick something manageable, understand why it exists, and involve the people who rely on it. If it can change, make the change and check whether it helped.

People want to do useful work, and good teams take pride in doing it well. As leaders, we have a responsibility to make sure their time goes toward work that still matters. Before we ask them to take on the next thing, it is worth asking what they no longer need to carry.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Your Team May Already Know What Needs to Change

A process can look perfectly reasonable until you sit beside the person who has to use it every day. The steps are documented, the application is running, and the reports say the work is getting done. Then someone shows you the spreadsheet they keep on the side, the information they enter twice, or the phone call they make because two systems do not quite agree. Suddenly, you understand why something that should take ten minutes takes most of the morning.

I have written recently about workarounds and the people whose knowledge becomes part of the system. There is another side to that conversation that deserves attention. Those same people may already understand what needs to change. We just need to make time to ask them, and be willing to hear the answer.

Over my 27 years in technology, I have come to appreciate how much you can learn from the people closest to the work. Product leadership, development, operations, support, and the business all see different parts of the same problem. A developer may understand why an application behaves a certain way, while the person using it understands what that behavior costs them throughout the day. We need both perspectives to make a useful decision.

Consider a customer service team that has to check several screens before answering a routine question. Each screen may serve a legitimate purpose, and each system may be working exactly as designed. But the customer is still waiting while someone gathers information that could be easier to find. If we only ask whether the systems are working, we can miss whether they are helping people do their jobs.

That is why I like a simple starting point: “Show me how you do this.” Let someone walk through the actual work, including the parts that never made it into the process document. Ask where they have to stop, what they have to check, and what they wish they did not have to do twice. Give them enough time to explain why those steps exist before deciding which ones should change.

There is a responsibility that comes with asking. If someone takes the time to explain a problem, they deserve more than a polite thank you followed by silence. We may not be able to fix everything immediately, and there may be constraints they cannot see from their part of the process. Good leadership means explaining those constraints, agreeing on what can happen next, and following through.

Experience matters here, too. An older process may contain a safeguard that was added after a costly mistake, or an exception that still serves an important customer need. The person who remembers that history can help us improve the process without creating the same problem again. Progress is much easier when we understand what we are building on.

Sometimes the right improvement is a product change. Sometimes it is clearer ownership, better training, or removing a step that no longer serves a purpose. The size of the change matters less than whether it makes the work more reliable and gives people time back. A small improvement that helps every day can be worth a great deal.

This is one of the things I enjoy about bringing people together across technology and the business. Someone understands the need, someone knows the history, and someone else knows how to build a better solution. Leadership helps those people work through the problem together and turn what they know into something useful.

Before the next planning meeting, it may be worth spending a little time with someone who uses the process every day. Ask them to show you where the work gets difficult, and listen carefully to what they explain. Your team may already know what needs to change. A good next step is making sure that knowledge reaches the people who can help.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Great Products Start with People Who Share a Purpose

As we close out the week, I want to recognize the value that product leadership, management, development, and the broader IT team can bring to a company. When people have clear direction, trust one another, and understand who they are working to help, they can accomplish some remarkable things.

Over my 27 years in technology, I have worked with people who bring very different strengths to the table. Some can listen to a customer and uncover a need that nobody has quite put into words. Others can turn that need into a practical plan, build the solution, or keep everything running reliably. Each contribution matters. A great idea needs people who can deliver it, and a great technical solution needs to solve a problem customers actually have.

That is where leadership makes a difference. Good leaders help people understand the purpose behind the work. They make priorities clear, welcome thoughtful questions, and help teams work through obstacles. They also listen when someone closest to the work sees a better approach. Direction matters, but so does giving capable people the support and trust to do their jobs well.

I think of that shared purpose as our north star. When a deadline gets tight or competing requests arrive, we need something to guide our decisions. Who are we helping? What problem are we solving? Will this make the customer’s experience better? Those questions bring the conversation back to the people who will use what we deliver.

Product leadership helps keep customer needs in view. Management brings coordination and accountability. Developers turn ideas into working products. Quality assurance helps us catch problems before customers encounter them. IT, security, operations, and support help make the experience dependable long after the release. The customer may never see all those people, but they experience the results of their work every day.

Some of the most rewarding moments in my career have been surprisingly simple. A customer no longer has to enter the same information twice. A frustrating process becomes easier to follow. A recurring issue finally gets resolved. Someone who was nervous about using a system begins to feel comfortable with it. Those improvements may not make headlines, but they can make someone’s workday considerably better.

Of course, a company needs to make money. Revenue pays the bills, supports employees, and makes future improvements possible. But there is pride and purpose in delivering something that earns a customer’s business. We should want people to feel that the product was worth their investment and that the company behind it cares about their experience.

Every profession has people who fall short. I have also worked with many who care deeply about doing a good job. They take responsibility, share what they know, help a teammate, and keep working until a problem is understood. With strong leadership and a shared direction, that commitment can become a tremendous asset to a company.

A positive team culture grows through everyday actions. It comes from recognizing good work, keeping promises, addressing problems fairly, and making it possible to ask for help. People need to know what is expected of them, and they need to know that speaking up about an obstacle is part of moving the work forward.

As we finish the week, I hope we take a moment to appreciate the people behind the products and services we depend on. The person asking a careful question. The developer improving a difficult workflow. The manager removing an obstacle. The support professional helping a frustrated customer. Their work adds up.

When we give people a clear purpose and help them succeed together, we can build products that serve real needs, strengthen a business, and make someone’s day a little better. That is work worth being proud of.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

When Your Best Employee Becomes Part of the System

I've seen this happen more than once over the years. Something breaks, nobody can quite figure out what's going on, and eventually somebody says, "Call John. He'll know."

Maybe his name isn't John, but almost every company that's been around long enough has one. He's the person who remembers why something was built the way it was, which customer needed that strange exception, or why a process that looks unnecessary absolutely cannot be removed. Having someone like that on your team is incredibly valuable. It can also create an incredible amount of risk.

When Knowledge Becomes Part of the Architecture

We normally think of architecture as applications, databases, integrations, servers, APIs, and all the other pieces that make a system work. But after enough years, people can become part of the architecture too.

The system works because Sarah knows to check something every Tuesday. A deployment succeeds because Mike knows about the extra step that isn't in the documentation. Support gets an unusual customer issue and immediately sends it to David because he's the only person who has seen it before. Eventually those things become normal, and nobody considers them a problem because the process works.

Until Sarah goes on vacation.

The Human Version of Technical Debt

In my last article, I talked about temporary fixes becoming permanent parts of a platform. I think undocumented knowledge works almost the same way.

One person learns something because they had to solve a problem. The next time it happens, everyone goes back to that person. Why spend three hours investigating something when Jennifer can solve it in ten minutes? It makes perfect sense at the time.

But every time we do that without transferring the knowledge, we make Jennifer a little more important to the operation of the system. Eventually she isn't simply an experienced employee. She's a dependency.

This usually doesn't happen because someone intentionally refuses to document what they know. The company is busy. Customers need things. Production issues happen. Projects have deadlines. Writing down something you already know how to do never feels quite as important as solving today's problem.

So we tell ourselves we'll document it later.

Sound familiar?

When Your Best People Become Bottlenecks

There's an irony here. The people most likely to become bottlenecks are often some of your best employees.

They're dependable. They know the product. They understand the customers. They've seen the mistakes before. When something important happens, they're exactly the people you want involved, so we involve them in everything.

Before long, they're answering questions all day, reviewing everyone else's work, joining every important call, troubleshooting production issues, helping Support, helping Product, and helping newer employees understand the system. Then leadership wonders why they aren't getting their own work done.

We've rewarded expertise by making it almost impossible for the expert to escape it.

Documentation Helps, but It Isn't the Answer

The obvious response is, "We need better documentation." Yes, we probably do. But I've also seen companies create hundreds of pages of documentation that nobody reads and that becomes outdated almost as quickly as it was written.

The real goal isn't documentation. The goal is knowledge transfer.

That might mean documentation, but it could also mean pairing people together, rotating responsibilities, or having another developer troubleshoot the problem while the experienced person helps instead of immediately taking over. Sometimes it simply means asking the person who knows something to explain why instead of always asking them to fix it.

There's a big difference between documenting steps and transferring understanding.

Can Someone Else Do It?

I think that's a surprisingly useful question for leaders to ask. If this person were unavailable for two weeks, could somebody else deploy the application? Could somebody else troubleshoot that integration? Could somebody else explain why this business rule exists? Could somebody else work with that important customer?

If the answer is consistently no, you've found organizational risk.

That doesn't mean the employee has done anything wrong. Quite the opposite. It usually means they've become extremely valuable. Our responsibility as leaders is to make sure their knowledge becomes valuable to the organization too.

The Goal Isn't to Make People Replaceable

Whenever this subject comes up, someone inevitably hears "knowledge transfer" and thinks we're talking about making employees replaceable. That's not how I see it.

The person who can solve every problem is valuable. The person who can help five other people learn how to solve those problems is even more valuable.

That's how teams mature. It's also how experienced employees get the opportunity to move forward instead of spending the next ten years being the person everyone calls whenever the same old system breaks.

A Healthy System Should Survive a Vacation

Maybe that's the simplest test. Your employees should be able to take a vacation without checking Teams every few hours. Someone should be able to get promoted without leaving a hole behind them. Someone should be able to retire after twenty years without everyone suddenly realizing that twenty years of business knowledge just walked out the door.

Technology companies spend a lot of time thinking about redundancy. We build redundant servers, storage, networks, backups, failover systems, and disaster recovery plans. Yet sometimes we'll allow one person to be the only person who knows how a critical part of the business actually works.

That's a strange kind of redundancy plan.

So perhaps there's another question we should ask when evaluating the health of an established platform:

What does the system know, and what do only our people know?

Because eventually people move on. The knowledge shouldn't have to leave with them.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

There Is Nothing More Permanent Than a Temporary Fix

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

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

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

Then something funny happens.

Nobody comes back.

The Problem Isn't Taking Shortcuts

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

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

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

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

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

And nobody really knows.

The temporary fix has become architecture.

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

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

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

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

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

Success Can Actually Make This Worse

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

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

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

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

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

Then the Firefighting Starts

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

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

Great. Crisis over.

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

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

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

We're refinancing it.

The Backlog Can Become a Graveyard

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

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

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

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

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

Some Debt Is Worth Carrying

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

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

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

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

Leave Breadcrumbs for the Next Person

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

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

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

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

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

Later has a funny way of never showing up.

And that's how temporary fixes become permanent platforms.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

When Your Technology Jokes Need a History Lesson

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

That happens more often these days.

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

Then there are the really fun conversations.

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

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

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

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

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

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

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

Of course I would!

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

Ten whole megahertz!

We were flying!

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

It may have been the greatest technological placebo ever invented.

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

I can still hear that modem connecting.

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

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

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

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

I’ve had a front-row seat.

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

And yes, I remember the TURBO button.

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

Some jokes simply require 27+ years of prerequisite experience.

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

You’ll never convince me otherwise.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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