After 25 years in tech, the lesson that keeps returning is simple: we're not building software — we're solving problems for people.

I've been a developer, an IT lead, a team player, a mentor, and someone lucky enough to work with brilliant people across many projects. The more experience I gain, the more I realize how noisy things can become — perfect code, elegant architecture, trending stacks. These are tools, not destinations.

These ten lessons aren't rules. They're patterns I've seen repeat across teams, tools, and titles — hard-earned, sometimes painful, always humbling.

At a glance

  • The goal is customer value, not perfect code or impressive architecture.
  • Complexity that doesn't serve the customer is a trap — clarity often beats elegance.
  • The real product is people, process, and trust — not what's visible in GitHub or dashboards.
  • Ship small, learn fast, measure what matters — including the signals that don't fit on a dashboard.

Lesson 1 — Don't lose sight of the goal

Everyone wants to bring their best game. We all want to contribute, share ideas, and deliver something great. But sometimes, the sheer volume of opinions becomes overwhelming. We hit analysis paralysis, where every voice insists on being heard and we lose sight of what we were really trying to accomplish.

The goal is not perfect code. It's not a beautifully animated website. Those things are tools, not destinations. The real goal is to deliver value to a customer — a practical solution to a real problem, one that matters enough for someone to invest in.

As technologists, we need to remind ourselves: we are in the business of solving problems, not showing off perfect solutions.

Lesson 2 — When clarity beats complexity

A few years ago, I was in a room with a dozen engineers architecting what was supposed to be a simple notification system. One person proposed a microservice per channel: SMS, email, push, Slack. It was elegant, abstract, and… a trap.

Someone quietly asked, "Do we really need this now? We only send password resets through email."

That comment saved us weeks. Instead of building four services, we built one, sent some emails, and moved on. The goal wasn't to build the system. It was to reset passwords.

Lesson 3 — Innovation that serves the customer

We often talk about innovation like it's a virtue by itself. But unless it serves someone, it's just noise. I once worked on a team obsessed with serverless. We rebuilt an entire API in Lambda functions because it was the trend. It worked — but it was hard to debug, difficult to scale, and nearly impossible for newcomers to contribute to.

Eventually, we admitted it: this didn't serve the customer better. It served our need to feel ahead of the curve. Real innovation is invisible to most users. It feels like ease, speed, confidence. The best tech quietly disappears.

Lesson 4 — Staying relevant in a changing market

Relevance is no longer about knowing every new technology. It's about understanding what truly drives value — connecting technical decisions to business outcomes. And yes, staying curious, humble, and willing to adapt.

Lesson 5 — The real product is people and process

At a fintech where I worked, I often said: our product isn't just the platform. It's the workflow we've created around identifying a problem, designing a solution, building it, testing it, deploying it, getting feedback, and doing it all over again. That feedback loop is the engine of innovation.

And that engine runs on people. The real value of the business is often overlooked because it's not visible in GitHub or dashboards. It's the culture, the trust, the ability of a team to iterate together toward the right thing.

It's not just DevOps. It's TrustOps. CultureOps. When people feel safe to challenge, ship, fail, and iterate — that's when velocity kicks in.

Lesson 6 — Shipping isn't the end

Just because you shipped something doesn't mean you're done. More often, it means you're just beginning. Technology should deliver something real, show how it performs, and make it better.

That's why I believe in baby steps — the smallest valuable version of the solution. Get it into users' hands. Learn. Adjust. Repeat. That's how you avoid building the "perfect sphere."

Lesson 7 — The illusion of perfect consensus

Reaching a consensus is an illusion. There is always someone who won't like the direction. In the pursuit of getting everyone to agree, we can water down good ideas until they lose their power.

If you believe in a strategic solution, fight for it — with evidence, not ego. Not every decision needs unanimous support. Sometimes leadership means having the courage to make a call when opinions diverge. Healthy disagreement produces better outcomes than artificial harmony.

Lesson 8 — How do you measure value?

Sure, you can track lead time, uptime, deployment frequency. These are useful. But I've come to believe:

If you can't measure it, it probably isn't the thing that matters most.

The true value often lies in things like:

  • A customer renewing without even asking for a discount
  • A developer saying, "This was the easiest system I've ever onboarded to"
  • A support person reporting, "Tickets went down this month"
  • A founder saying, "I sleep better now"

These aren't always KPIs. But they are the music behind the numbers.

Lesson 9 — Balancing craft with customer focus

We all want to write good code. Beautiful systems. Elegant design. And we should!

But I've learned to stop chasing purity. The best architecture is the one that lets you respond fast. The best code is the one that others can read and change. The best design is the one the customer never notices because it just works.

Customer focus doesn't mean cutting corners. It means aligning your effort with their outcome.

Lesson 10 — Work with the customer, not just for them

True collaboration means involving the customer early and often. Don't come in with a complete, polished solution that no one needed. Come in with an idea. A first draft. A starting point. Then shape it together.

After 25 years, I'm not here to impress anymore. I'm here to help. To guide. To ship. To listen. And to remind anyone who needs to hear it:

We're not building software. We're solving problems for people.

Related on this site

If these lessons resonate with how you want to lead technology in your organization, let's talk.