In 1854, Louis Pasteur wrote, Chance favors the prepared mind. More than 170 years later, it still remains the best way to extract the most out of chance events. Being prepared.

I have spent 30 years watching people I admire get “lucky.” They meet the right co-founder at a conference. They land a dream role because someone read their blog. They raise funding because an investor saw their open-source project. From the outside, it looks random. From the inside, it is not.

The luckiest CTOs I know do not wait for luck. They engineer it, much like they engineer the software they build. They put themselves in motion, prepare before opportunities arrive, and make themselves findable long before they need to be found. Luck is not a single event. It has layers, it rewards motion, and it favors the prepared. Here are five things I have learned about engineering it.

1. The Luckiest Engineers Are Not Lucky. They Are Prepared.

I learned early that luck works in layers. The Indian economic liberalization of the 1990s happened while I was studying software engineering. I had no role in it. That was blind luck, and I benefited from it. But most of what people call luck in a career is not blind. It is active, discerned, or personality-driven.

James Austin classified luck into four types in Chase, Chance, and Creativity. Only the first is accidental. The other three can be cultivated. The distinction matters because it shifts the locus of control. If luck is random, there is nothing to do. If luck is cultivated, there is everything to do. I have written about the four types of luck in detail here.

2. Motion Creates More Luck Than Talent Does.

In 1998, I was on the bench between projects. I could have spent these days sleeping in the library like everyone else. Instead, I started experimenting with sending emails programmatically using Visual Basic. That small experiment led me to a mentor who changed my career trajectory. The people who seem luckiest usually try more things than others. They launch more projects, meet more people, test more ideas. Most experiments fail. Nobody notices them. People only pay attention to the one that succeeded. And call them lucky.

3. The Best Career Moves Feel Like Wrong Turns at the Time.

When I was 10, I wanted to be a writer. I even joined a journalism course with all the pocket money I got. I went to college and studied engineering. When I graduated as an Electronics engineer, I wanted to be in computer graphics. I ended up in healthcare informatics. I went to the US expecting a green card, got transferred to Belgium, was forced back to India, and found myself advising the Government of India in Delhi. Each move felt like a detour. Each detour opened a door I could not have planned for.

I wrote about this in Life is a series of lost, found, and lucky breaks. Getting lost is not failure. A person cannot find a path without wandering first. The leaders who seem to have all the breaks are the ones who kept moving through the wrong turns instead of stopping in disappointment.

4. Luck Favors the Engineer Who Ships, Not the One Who Plans.

I have watched intelligent people stall because they never shipped anything. Meanwhile, the engineers who experiment in public, launch small projects, and share what they learn create more surface area for luck to find them. One of the main reasons people do not get lucky is surprisingly simple. Nobody knows they exist. Push code to GitHub. Write about what was built on LinkedIn. Create a portfolio that speaks louder than a CV. The experiments compound invisibly. What appears to be luck is often the result of countless small bets that nobody saw.

5. The Paranoid Prepare. And They Become Lucky.

I borrow this from value investing. When I buy a stock, I ask what’s the worst thing that can happen to the price of the stock. Will I still hold if that happens? If I can hold without panic, then I buy. This rule has helped me build a growing value based stock portfolio.

I apply the same thinking to career decisions. Before I commit to anything significant, I ask what could go wrong. I prepare for the worst outcome so that if it arrives, I am not shaken. Charlie Munger said, Tell me where I am going to die, so I will not go there. The paranoid do not freeze. They prepare. And when the storm arrives (they always arrive), the prepared are the only ones standing. I have written about this in Luck Loves the Paranoid. The thesis is simple. The paranoid prepare, hence prosper. Others perish. Margin of safety is not just for portfolios. It is for careers, for relationships, for every decision that carries real consequences.

Becoming Lucky In GenAI Era

Everyone is asking whether AI will take their job. I think the better question is whether I am positioning myself for the luck that AI is creating. I am already experimenting. I use ChatGPT and Claude regularly. I code with AI agents. I installed Hermes, an AI assistant that manages my workflows, reads my wiki, and drafts blog posts. I post my learnings on LinkedIn so others can see what works and what does not. I do not know if luck will find me. But if it knocks on my door, I will be ready. I will not be found wanting. If the past is any indicator, it will.

The tech leaders who thrive in the next decade will be the ones who experiment with agents now, publish what they learn, study trends before they are obvious, and make themselves findable to opportunities that do not exist yet. A career’s future luck depends on what a person does today.

Every career framework I have seen focuses on risk mitigation. Nobody teaches to prepare for luck. But luck is the higher-leverage variable. Prepare not only for storms, also for the day the wind is at your back.

Field Notes

Observation Luck is not a random event. It is the compound interest of motion, preparation, and visibility applied over years.

Question What are you doing this week that creates surface area for luck to find you?

Experiment Ship one small thing publicly this week. A blog post, a tool, a talk. One new pathway for luck.

Not GM.

They sent an engineer to investigate.

He went with the customer three nights.
Chocolate Ice Cream. Started.
Strawberry Ice Cream. Started.
Vanilla Ice Cream. Wouldn’t start.

The customer’s claim, however strange it seemed, held up. So he collected more data. Time of day. Gas type. Drive time. He noticed a pattern. Vanilla was the store’s most popular flavor, sold at the front for quick pickup. All other flavors were sold at the back. The vanilla trips were shorter.

He reframed the question. Not “why won’t the car start with vanilla ice cream?” but “why won’t the car start with less time between shutdown and restart?” The answer was vapor lock. The engine was still too hot.

That is the engineering mind. A way of seeing. The willingness to sit with a strange claim, collect evidence, and find the real question hidden behind the obvious one.

Last week, I published a roadmap.

After I published last week’s field note, Sumit summarized the post on LinkedIn and posted this:

It’s no longer about whether leaders still write code, but whether they can continue to think like engineers in a world where they may not be the ones producing it.

So the obvious question became: what is the engineering mind?

I didn’t know how to respond. It was like asking a fish to describe water. I’ve been doing this for thirty years. The thinking felt automatic. I couldn’t separate what I knew from what I was.

Then I came across two questions from TamizhVendan S that put words to it. Am I solving the right problem? Am I solving the problem right?

The GM engineer was doing exactly this. He reframed the problem (solving the right one) and then collected data to confirm his hypothesis (solving it right).

Last week I wrote that the builder is becoming a director. A director who has never laid bricks gives bad direction. These two questions are what the director needs.

How does it manifest in software development?

If the requirement is to build a customer dashboard for e-commerce, an engineer will clarify the specifics: is it all customers in the db or only those who bought in the last 30 days? Should it matter if they bought $1 or $1000? In my experience, clients often understand these questions differently. Asking these questions helps solve the right problem.

The second question is about architecture. Monolith or microservice? Which database? Which patterns? The agent can generate code for any of these. But which one fits the team’s capability, the scale requirements, the operational overhead? The engineer asks what’s simplest and what trade-offs are acceptable right now. Not in two years. Right now.

The technology is revealing what the engineering mind always was. When anyone can generate a working application, the scarce resource isn’t more applications. It’s knowing which ones are worth building, what’s elegant, and where they’ll break. That judgment has always been the engineering mind. The agentic era just made it impossible to ignore.

The thesis was simple: start by building things, then learn to design them well, then learn to scale them, then learn to think about platforms instead of projects. A developer who did all of that while learning to think clearly and communicate well would find the CTO office was the natural destination.

GenAI and agentic coding has impacted this roadmap. This post is an attempt to identify skills that still matter.

The market today says coding is dead. Developers should become prompt engineers. The old roadmap is obsolete. I have watched agents write code, deploy services, debug errors, and generate tests. I understand why the conclusion feels obvious. But the conclusion is wrong. Every layer still matters. What shifted is the work inside each layer.

The Build layer has not disappeared. It has changed shape. Old Build meant hand-coding every component, every endpoint, every test. New Build means prompting, setting context, managing memory across sessions, and breaking large problems into agent-sized chunks. The builder is becoming a director. But a director who has never laid bricks gives bad direction. The build skill is still essential. It is just taking a different form. I will write more about this in the next post.

The Design layer matters more now, not less. Especially for enterprise applications.

Early in my career, I was computerising a hospital department. I had a cyst. I asked a surgeon-intern what I should do. She grinned and said, “Operate.” It was a joke, but it made a point I have never forgotten: ask a surgeon, get surgery.

The same is true of an LLM. Ask it to build an application without context, and it will give back something. It might build for a complex user scenario when a simple one would do. It might build for a demo when the need is production-ready. Either way, it builds what was asked for, not what was needed. Nobody can guide what they do not understand. Design knowledge is what lets an engineer guide the master craftsman: coding standards, design patterns, monolith versus microservice, component decomposition. The LLM executes. The architect still draws the blueprint.

The Scale layer remains firmly in human hands. Agents help with DevOps scripts, monitoring configurations, index suggestions. But understanding what to monitor, which indexes matter, how to profile functions, and how to tune for growth: these judgements are not automatable yet. The tools changed. The thinking did not.

The Platforms layer is exactly what I said in 2021. Build versus Buy is now Buy versus Burn Tokens. Any serious business owner still defaults to buying over building. Platforms win because they compound. No revision needed.

Three skills cut across all four layers. In 2021, I named two: structured thinking and communication. I positioned them as late-career additions, things to pick up after proving technical competence. That was a mistake. They belonged at every level from the start. In 2021, these skills differentiated a developer from other developers. Today, they also differentiate a developer from an agent.

The third cross-cutting skill is something I have started calling agent fluency. It is not prompt engineering. It is knowing how to set context, manage memory across sessions, break large problems into agent-digestible pieces, and evaluate what the agent produces. It is the skill of working with agents the way a senior engineer works with junior engineers: clear direction, clear boundaries, clear evaluation criteria. This skill did not exist on the 2021 roadmap because it did not need to. Today, it cuts across every layer, from build to platforms.

The speed of change makes it impossible to track everything across tech, e-commerce, design, and adjacent domains. I built SophAI Radars to solve this. Pick your domains, and it turns hundreds of sources into editorial briefs readable in three minutes. It is how I stay current without drowning.

The pyramid still stands. What changed is who, or what, does the work inside each layer. This is how the roadmap looks like now. Let me know if I missed anything. I’m still figuring this out myself.

Field Notes

Observation
Every layer of the roadmap still matters. What shifted is the nature of the work inside each layer, and the skills needed to do it.

Question
Which layer of your work has shifted most in the last two years, and which have you neglected?

Experiment
For one feature this week, direct an agent with explicit design constraints: patterns, standards, component boundaries. Do not just describe what to build. Compare the output.

That idea assumes life is mostly a series of trade-offs.

Ryan Holiday shares advice from Austin Kleon that captures this way of thinking:

Work. Life. Scene. Pick two.

Work is how you earn a living. Life is your family and close relationships. Scene is everything else—parties, dinners, networking events, and the activities that fill social media feeds.

There is some truth in this. Time is limited. Every commitment leaves less time for something else.

But I think time is only part of the story.

Jeff Bezos offers a different metaphor.

It’s a flywheel, not a balance.

He explains that when work energizes him, he becomes a better husband and father. When life at home is good, he becomes a better leader at work. Each part strengthens the others instead of competing with them.

That idea has matched my own experience far more closely.

I’ve been fortunate that both my work and my family have been sources of energy. They rarely compete with each other. Instead, they reinforce each other. There are also times when a meal with close friends or a good conversation leaves me equally refreshed.

The common thread isn’t whether an activity belongs to work, family, or leisure.

The common thread is whether it gives energy or takes it away.

A job that constantly drains you eventually affects your relationships. A difficult home life eventually affects your work. Even recreation is not always replenishing. Some activities leave you more tired than when you started.

Perhaps the real question is not how to balance our lives.

Perhaps the better question is this:

What keeps my flywheel turning?

The activities will be different for each of us. For one person, it may be jogging. For another, it may be reading, spending time with family, serving in a church, or meeting close friends.

The important thing is not the category.

It is whether that activity generates enough energy to make every other part of your life better.

I no longer think of work, life, and fun as competing priorities.

I think of them as parts of the same flywheel.

When they generate energy, they reinforce one another. When they drain energy, the whole system slows down.

A long life is built not by separating and balancing work and life, but by integrating the two and filling it with the people and activities that keep the flywheel moving.

My manager said, “You have to learn to deal with ambiguity.”

At the time, I did not understand what he meant. I had come from a software engineering background, where ambiguity usually meant something had gone wrong.

As a developer, I lived in a world of clarity. The program either worked or it did not. The output either matched the specification or it failed. Computers reward precision, deterministic behaviour, and binary logic. That was the way I had been trained to think.

So when I heard that advice, I dismissed it as one of those management phrases that sounded important but did not mean very much.

I was wrong.

Over the years, I realised that this may be one of the most valuable leadership lessons I have learned.

The first place I saw it was in project planning.

Suppose you are planning a project that will run for a year. You gather requirements, estimate effort, identify risks, and prepare a detailed plan. Even after doing all that work, you still do not know what the next twelve months will bring. A key engineer may resign. Someone may fall sick at a critical stage. A third-party vendor may miss a delivery. The customer may change priorities halfway through the project.

None of these events are unusual. They are simply part of reality.

A project plan is not a prediction of the future. It is the best decision you can make with the information available today. Good project managers know the plan will change. They still make the plan because moving forward without one is worse.

Hiring taught me the same lesson.

You can interview a candidate several times, assess technical skills, evaluate cultural fit, and check references. Even then, you can make the wrong decision. Sometimes the person turns out to be different from what you expected. Sometimes life changes around them. A family emergency, an illness, or an unexpected opportunity can completely change the outcome.

The uncertainty never disappears, yet the hiring decision still has to be made.

As I moved into leadership roles, I realised that ambiguity was no longer an occasional part of my work. It had become the work itself.

Subscribe now

Today, as a CTO, much of my day is spent making decisions with incomplete information. A prospect asks a question during a sales call that nobody prepared for. You have to think on your feet and keep the conversation moving. A production issue is escalated before anyone knows the root cause. The person who was supposed to present to a customer suddenly becomes unavailable, so you step in. Every day brings situations where waiting for complete information is simply not an option.

That changed the way I think about planning.

I no longer think in terms of fixed plans. I think in terms of experiments.

I gather data. I form a hypothesis. I try something. If the evidence supports it, I continue. If it does not, I change direction and learn from the result.

Leadership often looks less like executing a perfect plan and more like running a series of thoughtful experiments.

The obvious question is whether you can become better at dealing with ambiguity.

I think you can.

The first step is to expand your capability.

Take on hobby projects that are different from your day job. Volunteer in professional associations. Speak at conferences. Put yourself in situations where you have to learn quickly and adapt. I would also add one more habit that has helped me over the years: read literature.

Engineering trains us to think in binaries. Literature trains us to understand people.

The best characters are rarely completely right or completely wrong. They are complex. They have strengths, weaknesses, contradictions, and motives that change over time. The more you read, the more comfortable you become with people and situations that do not fit neatly into categories. Leadership is full of those situations.

As your capability grows, your confidence grows with it. Ambiguity becomes less intimidating because you trust yourself to find a way through.

The second step is to practise uncertainty in small ways.

Our lives are full of tools that remove uncertainty. They are useful, but they also mean we get fewer opportunities to practise dealing with it.

Every now and then, drive without Google Maps. Explore roads you have never taken before. When you are bored, resist the urge to reach for your phone immediately. Let your mind sit with the uncertainty instead of filling every empty moment.

These are small exercises, but they teach your brain an important lesson. Uncertainty is not the same as danger. Most of the time, you can figure things out as you go.

Looking back, I think my manager understood something that I had not yet experienced.

As engineers, we are trained to remove ambiguity. As leaders, we are expected to make decisions in spite of it.

The higher you grow, the less certainty you have. You rarely have all the information. You rarely have all the time you want. Yet the decision still has to be made.

Leadership is not about having all the answers. It is about making the best decision you can before all the answers exist.

Then I entered the Indian IT industry. The boundaries disappeared.

Long hours became the norm. In fact, they were expected. Calls with customers in the US and the UK stretched into the night. Weekend work was part of the job. Nobody questioned it because everyone around us was doing the same thing.

The people who could endure it the longest were often admired.

When you’re twenty-five, it doesn’t feel like a problem. You recover quickly. You sleep less. You work through the night. You tell yourself this is the price of building a career.

I believed that too.

For almost two years I worked night shifts. By the end of it, my eyesight had weakened noticeably. Sometimes my hands would tremble when I stretched them out. I never thought much about it. It simply felt like one of those sacrifices you made if you wanted to get ahead.

The interesting thing about those sacrifices is that they rarely become expensive immediately. The bill arrives years later.

Subscribe now

Around the age of thirty-five or forty, many people enter the most exciting stage of their careers. They’re becoming architects, directors, senior directors, or moving toward executive leadership. The opportunities they’ve been working toward for fifteen years are finally within reach.

At almost the same time, what the job demands from you begins to change.

Work becomes less physical and more cognitive. You’re expected to make better decisions, influence more people, and deal with greater ambiguity. Outside work, children are growing up, parents are getting older, and financial responsibilities become heavier.

Your career demands more from you just when your body quietly starts offering less.

I’ve seen this happen often enough that it no longer feels like coincidence.

People who were once able to work twelve-hour days without thinking about it begin talking about poor sleep, weight gain, diabetes, high blood pressure, chronic fatigue, and stress that never quite goes away.

None of those things arrive overnight. They creep in slowly enough that we mistake them for getting older.

A few months ago I was reading Hacking Capitalism by Kris Nova. She argues that endurance isn’t really about how much you can exert. It’s about how well you replenish.

She isn’t alone. Dr. Vivek Murthy, the 19th and 21st Surgeon General of the United States, made a similar point in his commencement address at the University of Arizona:

The heart operates in two phases: Systole, where it pumps blood to the vital organs, and diastole, where it relaxes. Most people think that systole is where all the action is and the more time in systole the better. But diastole—the relaxation phase—is where the coronary blood vessels fill and supply life-sustaining oxygen to the heart muscle itself. Pausing, it turns out, is what sustains the heart.

Michael Phelps made a similar observation in an interview with Tim Ferriss:

For me to be able to do everything I need to do—from playing golf to having enough energy for my kids and everything else that matters—I have to recover.

When we’re young, we think career success belongs to the people who can keep pushing.

Maybe it belongs to the people who know when to pause.

We celebrate exertion because it’s visible. We rarely celebrate recovery because it looks unproductive.

Going for a walk doesn’t look like career development. Neither does sleeping seven hours a night. Neither does spending an evening with your family, reading a book, meeting a friend, praying, exercising, or pursuing a hobby that has nothing to do with work.

Yet these may be the very things that make a thirty-year career possible.

Eating well, sleeping enough, and staying fit aren’t separate from a career. They’re part of what makes a long career possible.

The professionals who sustain excellence over decades are not necessarily the ones who worked the hardest in their twenties. They’re the ones who arrive in their forties with enough physical and mental capacity to take on even bigger responsibilities.

Perhaps endurance was never about pushing harder.

Perhaps it was always about recovering better.

Field Notes

Observation

The bill for overwork usually arrives years after the work is done.

Question

What part of your future are you quietly borrowing from to succeed today?

Experiment

Protect one activity this week that replenishes you. Treat it as seriously as your most important meeting.

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.