When you’re the only person who understands a system, a customer, or a critical process, it feels like you’ve built a career moat. The project needs you. The company can’t afford to lose you.

Congratulations. You may have just reduced your chances of getting promoted.

You’ve become too valuable to move.

That sounds counterintuitive, but I’ve seen the opposite work throughout my career.

Whenever I took ownership of a role, I made it a habit to document what I knew. I shared my knowledge freely, not just what I knew, but how I thought through problems and made decisions. More importantly, I looked for someone who could eventually take over my responsibilities.

I wasn’t doing it because I wanted to leave the company.

I was doing it because I wanted to keep growing within it.

Looking back, this habit followed me from developer to consultant, from consultant to an e-governance advisor, and eventually to CTO. I don’t claim it was the only reason those opportunities came my way. But I do believe it made each transition easier. Every time I moved into a new role, someone else was already capable of carrying much of what I had been doing.

Over the years, I’ve come to believe something simple: Organizations don’t promote people because they’re indispensable. They promote people because they’re movable.

Subscribe now

Your next promotion often depends on whether someone else can do your current job.

Whenever I explain this, the first question I get is, “If I teach someone everything I know, won’t they replace me?”

It’s a reasonable fear. But in my experience, it happens far less often than people imagine.

Yes, people resign. They move to another team. Sometimes the person you’ve invested in isn’t around when the opportunity comes. Those risks are real.

But over the long run, organizations are far more willing to promote someone who has already built the next layer of capability than someone who leaves a vacuum behind.

When I started learning about stock market investing, I came across something Charlie Munger often talked about: inversion.

Instead of asking, “How do I become indispensable?”, ask the opposite question:

“What would prevent me from getting promoted?”

The same inversion showed up during the Second World War in Abraham Wald’s analysis of damaged aircraft. Engineers studied aircraft returning from combat and wanted to reinforce the areas with the most bullet holes. Wald suggested looking at the problem from the opposite direction. Those aircraft had survived despite those hits. The planes that never returned had probably been hit somewhere else.

The answer was found by looking in the opposite direction.

Careers can work the same way.

Most of us optimize for job security. Organizations optimize for mobility. Those aren’t always the same thing.

This doesn’t mean becoming replaceable because you’re average.

Quite the opposite.

You still have to become exceptionally good at what you do. In fact, the better you become, the more important it becomes to share what you’ve learned. You can’t teach what you don’t know.

The goal isn’t to become replaceable because you’re ordinary.

The goal is to become replaceable because you’ve multiplied your knowledge through other people.

Organizations don’t grow because they have indispensable people. They grow because those people build others who can carry the work forward.

The goal isn’t to become impossible to replace. The goal is to leave every role stronger than you found it, so that when the next opportunity comes, your organization can move you with confidence instead of keeping you exactly where you are.

It seemed obvious. If I became technically better than everyone around me, better opportunities would naturally follow. Promotions, bigger projects, and better pay would simply be a reward for becoming a stronger programmer.

Looking back over thirty years, I think I was asking the wrong question. I didn’t need to become the best programmer. I needed to become more valuable.

Those sound like the same thing, but they are not.

In India alone, there are millions of software professionals. Every year, thousands more join the industry. Even if you become exceptionally good at a particular language, framework, or platform, there will always be many others with similar technical skills.

Technical excellence is still essential. It is the foundation of our profession. But I no longer believe it is enough to build an exceptional career.

Over the years, I noticed something interesting.

The people who kept getting pulled into the important meetings weren’t always the strongest programmers. They were the people who could sit with a customer, understand the business problem, discuss the technology, and then come back and explain it clearly to the engineering team.

They could move comfortably between different worlds.

Years later, I came across Scott Adams’ idea of a talent stack. He describes how combining several complementary skills can make you more valuable than trying to become the very best at just one.

His idea gave a name to something I had already been experiencing.

Technology remained my foundation. Everything else became a multiplier.

The first multiplier was breadth. While I developed deep expertise in a few areas, I also tried to understand the rest of the stack. Front end, back end, databases, cloud, mobile, architecture—I didn’t need to master every one of them, but I wanted to understand how they fit together. That made it much easier to have meaningful conversations across teams.

The second multiplier was business. I became curious about how companies actually worked. What increased revenue? What improved profitability? Why did one project get approved while another was rejected? How did sales, marketing, finance, and operations think about success? The more I understood the business, the better my technical decisions became.

The third multiplier was communication. I learned to explain technical ideas in language that business people could understand. I learned to listen carefully to customers, understand the problem they were really trying to solve, and translate that into something my engineering teams could build. I also learned to explain technical constraints without hiding behind technical jargon.

Subscribe now

As those skills came together, people started calling me for different reasons.

Sales teams wanted me on customer calls because I could discuss both business and technology. Engineering teams relied on me because I could explain what the customer actually needed. Business leaders trusted me because I understood the commercial side as well as the technical side.

That’s when I realized these skills weren’t simply adding to my career. They were multiplying the value of the technical skills I already had.

That multiplication opened doors I had never planned for. It led me into government consulting, customer-facing roles, public speaking, leadership, and eventually the CTO role.

None of those opportunities came because I became the best programmer. They came because programming was no longer the only thing I brought to the table.

I no longer think the goal of a technology career is to keep adding technical skills forever.

The goal is to build a combination of skills that makes your technical expertise more valuable every year.

Keep building your technical foundation. Understand business. Learn to communicate clearly. Each new skill doesn’t replace the previous one. It multiplies it.

I never became the best programmer.

I simply became a programmer whose value kept growing because every new skill multiplied the ones I already had.

Skills don’t add. They multiply.

Talent matters. Skills matter. Hard work matters.

But there is something else that quietly shapes a career long before talent has a chance to prove itself.

It is the set of beliefs we carry about ourselves, other people, and what is possible.

The interesting thing is that these beliefs often remain hidden. In normal day-to-day work, they are difficult to see. They usually reveal themselves when an opportunity appears, when pressure arrives, or when we are asked to step outside our comfort zone.

Many years ago, I was managing a group that provided L2 support for several applications used by a large American insurance company. We worked night shifts to align with US business hours.

One day, a ticket arrived and the employee responsible for handling it came rushing to me.

He explained that when he added the digits of the ticket number together, the total came to eight. For him, eight was an inauspicious number. It was the first ticket he was handling, and he did not want to acknowledge it.

I remember telling him that failing to acknowledge the ticket within the required time would be far more inauspicious than the number itself.

The ticket was not the real issue. The issue was the belief behind it.

What we believe affects how we respond when opportunities and responsibilities show up. Sometimes the opportunity is obvious. Sometimes it is disguised as a problem that nobody else wants to handle.

Over the years, I have seen many versions of this.

But the most important example was my own.

For a long time, I believed I was an introvert. The problem was not that I was introverted. The problem was the meaning I attached to that label.

I convinced myself that sales was not for me. Customer conversations were not for me. Public speaking was not for me.

Without realizing it, I had built a fence around my own career.

The opportunities were there, but I had already decided they belonged to someone else.

Over time, through reading, conversations, training, and experience, that belief started to change.

Today, I am not a salesperson.

But I enjoy customer conversations. I enjoy helping sales teams. I enjoy presenting ideas, speaking at events, and explaining technology to clients and prospects.

The opportunities did not suddenly appear. They were always there. What changed was the way I saw myself.

The biggest obstacles in my career were technical. Most of the technologies I learned eventually became obsolete anyway.

The bigger obstacles were often the beliefs that told me what I could or could not do.

Every time one of those beliefs changed, new opportunities appeared.

Another experience taught me a different lesson.

Early in my career, I joined a new project and was assigned to work with a colleague who was supposed to help me understand the system.

He spent about twenty minutes showing me a few screens and giving me a quick overview. Then he was done.

I walked away frustrated. I assumed he did not like me. I assumed he did not want to share information. I assumed he saw me as competition.

Later, while having coffee with a friend, I mentioned the situation.

My friend laughed.

“Joe, you’ve completely misunderstood him. He’s new to the company, new to the city, and not comfortable speaking English. Give him some time.”

My interpretation had been completely wrong.

Over time, that colleague and I became very good friends.

That experience taught me that beliefs do not only shape how we see ourselves. They also shape how we see other people.

And when we misread people, we often miss opportunities to learn from them, work with them, and build relationships that could help us grow.

One conversation changed my thinking more than any book or course.

For many years, I struggled with an inferiority complex. A close friend who knew me well finally said something that stayed with me.

“Joe, you are neither inferior to anyone nor superior to anyone. God has created all of us equal.”

It was a simple statement. But it changed how I viewed myself and others.

After that conversation, I stopped comparing myself with others. I became more willing to take on responsibilities that I would previously have avoided.

Slowly, I became comfortable speaking in front of groups, engaging with customers, leading teams, and stepping into situations that once felt intimidating.

The belief changed first. The skills came later.

Over a long career, I have seen people with extraordinary talent remain stuck.

I have also seen people with average talent grow far beyond what anyone expected. The difference was often not intelligence, education, or technical skill. The difference was how they viewed themselves and the opportunities around them.

When an opportunity appeared, some people immediately found reasons why it was not for them. Others raised their hand and figured things out along the way.

The second group usually grew faster.

Not because they were more talented. Because they were less limited by the beliefs they carried.

I am reminded of Paul’s words about being transformed through the renewing of our minds.

Many of the beliefs that shape our careers come from family, culture, past experiences, fears, failures, and assumptions we have never taken the time to examine.

Yet those beliefs quietly influence our decisions every day. They influence which risks we take. Which opportunities we pursue. Which people we learn from. And ultimately, how far we grow.

Most opportunities do not arrive with certainty attached to them. They usually arrive disguised as responsibility, discomfort, risk, or change. Whether we step forward or step back often depends on what we believe.

And over time, what we believe may do more to determine our career growth than our talent ever will.

You need to see the future. And you need to deliver the present.

Most leaders are naturally stronger at one than the other.

Every executive title has two common words: Chief Technology Officer, Chief Financial Officer, Chief Operations Officer, Chief Sales Officer.

Most people focus on the second word. Technology. Finance. Operations. Sales.

That makes sense. Most leaders spend years developing expertise in their chosen function. It is often that expertise that earns them a seat at the executive table.

After spending a few years in the C-suite, I have come to believe the more important words are the other two.

Chief and Officer.

When I first became a CTO, I assumed technology would occupy most of my attention.

It certainly occupies some of it.

What surprised me was how often the real challenges had little to do with technology itself.

The difficult questions were usually about the future.

• Where should we place our bets?

• Which opportunities should we pursue?

• What capabilities would matter three years from now?

• What should we stop doing so we could focus on what matters?

Those questions led me to a deeper question.

What exactly does it mean to be a Chief?

Peter Thiel describes four views of the future. Some people are optimistic. Some are pessimistic. Some believe the future can be shaped. Others believe it simply unfolds.

The people who stand out are determinant optimists. They have a specific view of a future they want to create.

John F. Kennedy did not simply say that space exploration was important. He declared that America would put a man on the moon and return him safely to earth before the decade ended.

Jeff Bezos wrote in 1997 that online commerce would eventually accelerate discovery through personalization.

Elon Musk laid out a sequence of steps that would lead to affordable electric vehicles.

Whether you agree with them or not, these leaders had something in common.

They saw a future before others could see it.

That is the work of a Chief.

A Chief looks around corners. A Chief connects dots. A Chief reads broadly and thinks across domains. A Chief develops a point of view about where the organization should go.

But that is only half the title.

The second half is Officer.

An Officer is responsible for results. An Officer turns ideas into action. An Officer allocates resources, removes obstacles, builds teams, and creates accountability.

Without Officers, visions remain presentations, strategy documents, and keynote speeches. Nothing changes until somebody does the hard work of turning an idea into reality.

What I have observed is that leaders often become trapped on one side of the title.

Some become all Chief. They talk strategy. They discuss industry trends. They attend conferences and paint compelling pictures of the future. But little changes inside the organization.

Others become all Officer. Their calendars are full. Their inboxes overflow. They spend their days solving problems, responding to issues, and moving from meeting to meeting. But they rarely lift their heads long enough to ask where the organization is actually headed.

One group has direction without progress. The other has progress without direction.

Neither is enough.

I see this tension play out almost every day in conversations about AI.

It is easy to paint a picture of the future:

• The future of commerce is agentic commerce.

• AI agents will transform customer service.

• Software development will become AI-assisted.

• Search will become conversational.

• Workflows will become autonomous.

The difficult part is making any of it real. The vision may be clear, but reality has a way of showing up. Budgets are limited. Teams need training. Security and governance concerns need answers. New technology must coexist with old systems. And business leaders still expect results this quarter, not three years from now.

Seeing the future is exciting. Delivering it is hard.

That is why the best executives I have observed seem comfortable living in both worlds.

They can think strategically and act operationally. They are simultaneously visionaries and operators.

This is the defining challenge of executive leadership. Not choosing between vision and execution. Holding both at the same time.

To borrow from a popular saying, vision without implementation is an illusion. The opposite is equally true. Implementation without vision is one of the surest paths to defeat.

Every executive title contains both a C and an O. Most people spend their careers mastering one. The challenge is learning to master both.

A few years later, Visual Basic arrived. I achieved the same result with a single line of code. After spending months learning the hard way, I wasn’t sure whether to celebrate or use my Charles Petzold book as a pillow.

Over the last 30 years, I’ve watched the same movie play out again and again.

People who define themselves by a task struggle through these transitions. People who define themselves by the problem they solve usually find a way forward.

The code became easier. The business problem didn’t.

Users still needed applications. Businesses still needed solutions. The value had simply moved to a different place.

Did that make me a weaker developer? Of course not.

I went from typing hundreds of lines of code to designing screens and building applications by dragging and dropping text boxes, labels, and buttons. The new visual tools made it easier to solve business problems that users could actually see. And problems users can see are usually the ones businesses are willing to pay for.

New technology had arrived, but the question was the same as it is today: Was my job typing code, or solving a business problem?

Then the next wave arrived.

One of the first packaged applications I worked on was Vantive, a CRM product. Before packaged software, every customer implementation required building screens, workflows, databases, and business logic from scratch. Vantive came with much of that already built in. Instead of building everything, we configured, customized, and extended what was already there.

Projects that once took years could often deliver a first release in a quarter.

Again, the work changed. Developers moved from coding everything new to customizing existing elements.

My role changed as well. Before packaged software, my value came from building things. With packaged software, my value came from understanding both the customer and the technology. When I knew both, I could map out what was possible by default, what could be customized, and what could not be done.

Looking back, I was an early version of what we now call a forward-deployed engineer. The deeper lesson I learned was that technology careers are rarely about the technology itself.

I did not stop creating value because I stopped coding. I simply created value differently.

That is why I view the current AI discussion through a different lens.

Subscribe now

I agree with Jensen Huang’s observation that jobs are really collections of tasks. Some tasks will disappear. Some tasks will be transformed. Some entirely new tasks will emerge. The question is not whether tasks will change.

I’ve seen this movie before. The tools change. The job titles change. The anxiety remains remarkably consistent.

Every technology wave forced me to answer the same question: What exactly is my job?

Was my job typing code, designing screens, configuring software, or was it helping businesses solve problems using technology?

If I had defined my job as typing code, I should have become obsolete when 100 lines became one.

If I had defined my job as designing screens, I should have become obsolete when packaged software arrived. Neither happened.

Because my real job was never typing code or drawing screens. My real job was solving business problems with technology.

I’m reminded of an old story about stonecutters. A traveler asks one worker what he is doing.

“I’m cutting stones.”

Another says:

“I’m building a cathedral.”

A third says:

“I’m helping bring people closer to God.”

All three are doing the same work, but they have very different definitions of their job.

The same idea appears in business. People often think they are selling drills. Customers do not want drills. They want holes.

And even that is not the whole story.

Often they do not want holes. They want to hang a family photograph on a wall.

The farther you move from the task and toward the outcome, the more resilient you become when technology changes.

That is the real lesson of AI.

If you believe your job is typing code, creating data tables, configuring screens, or performing a specific task, the next few years may feel uncomfortable. But if you believe your job is solving customer problems, improving business outcomes, creating value, or helping people achieve something they could not achieve before, there will continue to be opportunities.

The tools will change. They always have.

The people who thrive are the ones who keep redefining their role around the problem, not the tool.

That has been true throughout my career, and I see no reason to believe AI will be any different.

Every major technology shift in my career forced me to answer the same question:

What exactly is my job?

AI is simply the latest version of that question.

So don’t ask whether AI can do your current task. Ask yourself a harder question: What problem do I solve, and how can I use AI to solve it better?

The answer may determine who thrives in the next decade.

CTO Field Notes captures observations, lessons, and questions gathered over three decades working at the intersection of technology, business, and faith.

The theme that connects them all: Observe. Wonder. Grow.

If a note sparks a thought, a question, or a different perspective, I’d love to hear from you.

Over the last few years, I’ve changed the way I learn new technologies. Instead of starting by understanding how they work, I start by understanding what they can do. I’ve come to think of this as moving through three stages:

• Driver,

• Mechanic, and

• Assembler.

The more technologies I encounter, the more convinced I am that most people should start as a Driver.

That wasn’t always my approach.

Over the last 30 years, I’ve lived through several technology waves: client-server systems, GUI programming, the internet, mobile, cloud, machine learning, and now GenAI. My instinct as an engineer was always to open the hood first.

If I was learning a GUI technology, I didn’t just want to know that window.alert() displayed a message. I wanted to understand exactly what happened after I typed it.

The same was true when I learned about the internet. I wanted to understand HTTP requests, DNS resolution, servers, application routing, and everything in between.

Curiosity served me well, but it also had a downside. I could spend a lot of time understanding how something worked before I understood whether it was actually useful.

GenAI is where I consciously flipped that model.

Driver

Think about learning to drive a car.

Most of us don’t begin by studying how fuel is converted into motion. We don’t start with the braking system, the steering linkage, or the transmission. We get into the car and drive it. We drive it in the city, on the highway, and up steep hills. We learn what it can do, where it performs well, and where it struggles.

Only after spending time behind the wheel we become interested in what’s happening under the hood.

That’s the approach I took with GenAI.

As soon as ChatGPT became available, I started using it. I used it to create policy documents for work. I used it to generate images. I used it to learn new subjects, research stock investing, rewrite essays, prepare sermons, and explore ideas. Whenever a new model appeared—ChatGPT, Claude, Perplexity, Mistral, and others—I took it for a drive.

At that stage, I wasn’t interested in model architectures, vector databases, or training techniques. I simply wanted to understand what these tools were good at and where they failed. I wanted to know what they could do for me.

The goal wasn’t to understand how the technology worked. The goal was to become proficient at using it. I wanted to master what the tool could do for me before I spent time learning what was happening under the hood.

Mechanic

After spending enough time as a Driver, curiosity naturally returned.

Now I wanted to know why certain things worked and why certain things didn’t. I started exploring APIs. I experimented with Open WebUI. I learned about system prompts, prompt storage, memory, context windows, and output processing.

What changed, however, was my intent.

Earlier in my career, I often felt the need to understand everything. With GenAI, I found myself learning only what was useful. Instead of studying the entire engine, I opened the hood to understand the parts that helped me get better results.

That distinction turned out to be important. I was no longer learning for the sake of completeness. I was learning to improve capability.

Assembler

Eventually, I found myself doing something different again.

I wasn’t just using AI tools, and I wasn’t just customizing them. I was starting to combine them to develop personal applications.

Claude helped me create requirements. I generated code via Google’s Antigravity. Cursor reviewed the code. I used LLM Models via Open Router. I also experimented with AI Agents. Instead of looking for a single tool that did everything, I started assembling workflows from multiple components.

This felt very similar to building a custom car. The engine comes from one place. The dashboard comes from another. The wheels come from somewhere else. Individually, they’re useful components. Together, they become a system.

Today, much of my experimentation with AI happens in this stage. I’m constantly trying different combinations of tools, models, prompts, and workflows to see what new capabilities emerge.

What Surprised Me

One of the things that surprised me most is that many non-technical people naturally start as Drivers.

Most people don’t care how a mobile phone works. They don’t need to understand radio frequencies, processors, operating systems, or network protocols. They care about what the phone helps them accomplish.

Because of that, they often adopt new technologies faster than engineers.

As technologists, we sometimes assume that understanding must come before usage. In practice, I’ve found that usage often creates the motivation for understanding. Once you see value, you have a reason to learn more.

So What?

I’ve found this Driver → Mechanic → Assembler progression to be a much more effective way of learning new technologies.

Start by driving it. Use it in real situations. Discover where it helps and where it falls short.

Then become a mechanic. Open the hood and learn enough to improve how you use it.

Finally, become an assembler. Combine components into systems that solve larger problems.

Understanding how things work is still valuable. In fact, it’s essential if you want to customize, improve, or build. But I’ve learned that understanding doesn’t always have to come first.

Curiosity about the engine is a wonderful thing.

Just don’t let it stop you from taking the car for a drive.

I am a CTO. I spend my days working with CEOs, business unit heads, directors, and technology teams.

Outside of work, I serve in churches. There, I work with pastors, ministry leaders, volunteers, and members.

Over the years, I began to notice a pattern that appeared in both worlds.

The incentives are different.

The environments are different.

The language is different.

Yet the problems people grapple with are often the same.

People wrestle with purpose, influence, trust, ambition, identity, growth, failure, leadership, and change. Whether the setting is a boardroom, a project meeting, or a church gathering, the patterns often rhyme.

As I encountered these patterns, I started keeping notes.

Each observation became a field note.

Over time, some observations revealed recurring patterns.

Some patterns became hypotheses.

Some hypotheses were reinforced by experience, tested through conversations, or sharpened by ideas I encountered in books and other people’s stories.

Many remain unfinished questions.

These observations come from the different arenas I inhabit—technology, leadership, career growth, faith, family, and lifelong learning. Together, they form the field notes collected here.

They are not lessons.

They are not declarations of truth.

They are observations from the field.

Most of the time, I am not writing because I have reached a conclusion. I am writing because I have noticed something and I am trying to understand it. I am thinking out loud and inviting others into the conversation.

Perhaps the observation is right.

Perhaps it is incomplete.

Perhaps it is entirely wrong.

The only way to know is to examine it together.

If these notes help even one person think more clearly, lead more wisely, navigate a career more intentionally, or make sense of their own experiences, then they will have served their purpose.

Subscribe. Read. Question.

Most importantly, make your own field notes as you build your career and your life.