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/

 

Being a Senior Developer Is About More Than Writing Better Code

Being a Senior Developer Is About More Than Writing Better Code

One thing I have learned over the years is that the word "Senior" in Senior Developer shouldn't simply mean someone who has been writing code longer. Experience certainly matters. Technical knowledge matters. Knowing languages, frameworks, databases, APIs, and architecture matters. But I think there is something else that separates a truly senior developer from someone who is simply an experienced programmer.

It is judgment.

A junior developer is often focused on completing the task in front of them. There is nothing wrong with that. We all started there. Here is the requirement. Here is the ticket. Build it, test it, and move it forward.

As developers gain experience, though, I expect the questions to change. Should we be doing this? What else could this change affect? Does something like this already exist elsewhere in the application? What happens to existing customers? What happens to the database? Could this introduce a security problem? How will Support troubleshoot this six months from now? What happens when the next developer has to modify it?

Those questions aren't necessarily written in the ticket, but they can be just as important as the requirements that are.

Senior Developers See Beyond the Ticket

One of the biggest differences I see between junior and senior thinking is the ability to look beyond the immediate assignment. A ticket might say, "Add this field." That sounds simple.

But where does the data come from? Where is it stored? Who can see it? Can it be changed? Should changes be logged? Does it need to appear in reports? Does an API need to expose it? Will another system depend on it later?

Suddenly, "add a field" isn't quite as simple as it sounded.

A senior developer understands that software is interconnected. Changing one thing can have consequences somewhere else, and those consequences aren't always obvious.

Sometimes the Best Developer Is the One Who Slows Things Down

This might sound strange in an industry obsessed with speed, but sometimes the most valuable person in the room is the one who says, "Before we build this, let's make sure we understand the problem."

That isn't resistance. That is experience.

I'd rather spend another hour understanding a requirement than spend the next three weeks fixing something we shouldn't have built that way in the first place. I've said before that we shouldn't automate bad processes. The same principle applies here. Writing code faster doesn't help much if we're solving the wrong problem.

Ownership Matters Too

I also believe seniority comes with ownership. When something breaks in production, the question shouldn't immediately be, "Whose ticket was this?" The better question is, "What happened, how do we fix it, and how do we prevent it from happening again?"

Good senior developers help junior developers understand why something happened instead of simply fixing it for them. They document what they learn. They question patterns that repeatedly create problems. They help improve the process, not just the code.

Most importantly, they understand that their responsibility doesn't necessarily end when the code is merged. The software still has to live in the real world.

AI Makes Judgment Even More Valuable

This becomes particularly interesting as AI continues changing software development. AI can already generate code remarkably quickly, and that capability is only going to improve.

So if writing code becomes easier and faster, what becomes more valuable?

Judgment.

Understanding architecture. Understanding customers. Recognizing risk. Knowing when a solution is becoming unnecessarily complicated. Seeing how today's decision could become tomorrow's technical debt. And sometimes knowing when not to write code.

I don't think AI diminishes the importance of senior developers. I think it makes genuine senior-level thinking even easier to recognize.

Because being senior was never supposed to mean simply being the fastest person at the keyboard.

It means understanding what happens after you press Enter.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

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

From Building Things to Building Teams

In the first two parts of this series, I talked about going from building houses to becoming a Web Developer and about spending more than 27 years adapting as technology continually changed.

But there's another change that happened along the way.

My definition of what it means to build something changed.

Early in my career, much of my value came from what I could personally do.

Could I write the code?

Could I troubleshoot the problem?

Could I configure the system?

Could I figure out why something wasn't working and fix it?

Those skills mattered, and that experience still matters today.

But somewhere along the journey, I realized my greatest contribution wasn't necessarily going to come from personally doing every technical task.

It was going to come from helping other people succeed at doing them.

That's a very different skill.

If I'm leading developers, I want developers who are better developers than I am.

If I'm working with database professionals, I want people who understand databases more deeply than I do.

I want infrastructure and security people who will challenge my assumptions. I want product people who understand the customer. I want people earlier in their careers bringing new ideas, new technologies, and different ways of thinking to the table.

I don't need to be the smartest person in the room.

I need to help create a room where smart people can succeed together.

That means providing direction without trying to control every decision.

It means asking questions.

It means removing obstacles.

It means recognizing when someone needs help and when they need room to figure something out themselves.

It means allowing people to challenge you.

And sometimes it means letting someone make a mistake, helping them understand what happened, and giving them another opportunity.

This is also where I've learned that product management and people management are very different things.

Product management asks: What should we build? Who are we building it for? What problem are we solving? Why does it matter?

People management asks: Does the team understand where we're going? Do they have what they need to succeed? Are we developing people or simply assigning them work? Are we creating future leaders?

Both matter.

And when you're leading technology organizations, eventually those worlds meet.

Sometimes you're creating a new product.

Sometimes you're fixing one that isn't working.

Sometimes you're modernizing something that has served the business well for years but needs to evolve.

And sometimes you're evaluating something completely new, like AI, and trying to determine where it genuinely belongs.

My job today isn't necessarily to personally write every line of code, configure every server, or know every command.

There are talented people who can do those things far better than I can.

My job is to bring those people together and help point them toward the goal.

When I think back to where this journey started, there's something almost fitting about it.

I started out building houses.

Then I learned how to build technology.

Eventually, I learned how to build products.

And somewhere along the way, I learned that one of the most rewarding things you can build is a successful team.

The tools have certainly changed over 27+ years.

I'm sure they'll change many more times before I'm finished.

That's okay.

I'm still learning.

I'm still adapting.

And I'm still interested in figuring out what we can build next.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

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

The Technology Changed. The Need to Keep Learning Didn't.

In Part 1, I talked about starting my career as a carpenter building houses in the Washington, D.C. area while going to school and trying to find my way into technology.

Eventually, I got my opportunity as a Web Developer during the dot-com boom and Y2K era.

That was more than 27 years ago.

A lot has changed since then.

I've watched technologies that were once considered cutting-edge become obsolete. I've watched development languages and frameworks come and go. I've watched infrastructure move from physical servers to virtualization and the cloud. I've watched software evolve into SaaS platforms, mobile become part of everyday life, automation change business processes, and now artificial intelligence begin changing how we work again.

Every one of those changes required learning something new.

And I'm still learning today.

I use AI regularly. I'm interested in what it can do, where it can improve productivity, and how it can change the way we develop products and solve business problems.

But experience has also taught me not to confuse new with better.

That's an important distinction.

After enough years in technology, you start recognizing patterns.

I've seen organizations automate bad processes instead of asking whether the process itself should exist.

I've seen teams repeatedly fix symptoms because nobody had the time, authority, or inclination to find the root cause.

I've seen technical shortcuts that saved a few days eventually cost months.

I've seen organizations choose technology first and then try to figure out what business problem it was supposed to solve.

The names of the technologies change, but many of the underlying problems don't.

That's where I believe experience becomes particularly valuable.

Experience doesn't mean walking into a room already knowing the answer.

If anything, experience has taught me to be more comfortable saying, "I don't know. Let's figure it out."

But it has also taught me which questions we should probably ask before we start looking for the answer.

What problem are we actually trying to solve?

Why are we doing this?

Who does it help?

Are we fixing the root cause or another symptom?

Are we making something better, or simply making it newer?

And increasingly today: Are we using AI because it genuinely improves the outcome, or because AI happens to be the technology everyone is talking about?

Those questions aren't anti-technology.

They're exactly the opposite.

Technology is incredibly powerful when we apply it to the right problems.

I've spent more than 27 years watching the tools change, and I expect they'll continue changing faster than ever.

I'm not an expert in every new programming language, platform, framework, or AI tool that appears.

I don't need to pretend that I am.

What I do need to do is remain curious enough to learn, experienced enough to ask questions, and humble enough to surround myself with people who know things I don't.

Because after all these years, one lesson has remained remarkably consistent:

The best technology professionals aren't the people who already know everything. They're the people who never stop learning.

In Part 3, I'll talk about another change that happened along the way.

At some point, my career became less about the things I could personally build and more about the people I could help build them.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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