Author: kevin

The Director to CTO Path: How to Follow It, or How to Mentor It

Why the leap from Director to CTO is really three distinct shifts, and how to start making them before you have the title

Montreal, Canada – Photo by Kevin Goldsmith – February 2026

If you want to move from Director to CTO, the real secret is this: you don’t make one giant leap. You make three distinct shifts: to your focus, your horizon, and your sense of what leadership means. This article will break down the three shifts so that you can see the real path ahead.

Before I get into this, I want to be clear. My path to CTO will not be your path. Every CTO I know got there in a different way. Most of us started as developers, then moved into engineering management and worked our way up. But the companies we worked for, the time we spent at each level, the opportunities we had, and the choices we made along the way vary wildly. There is no one true path.

My CTO experience is mainly with mid-sized startups (Series C-D, 150–a few hundred employees, engineering teams of 50–200). I’ve also worked at early-stage (places you’ve never heard of) and large companies (IBM, Microsoft, Adobe, Spotify), and I mentor leaders across company sizes, so I’ll bring those varied perspectives. But if you want to be CTO at a 10,000-person enterprise, someone who’s done that will be a better guide.

That said, the three key shifts I describe: broadening your focus, extending your strategic horizon, and evolving your definition of leadership, are still relevant in larger enterprise environments. The specifics may differ: for example, decision-making is slower, your “company-wide” focus as a technology leader can mean navigating far more complex org structures, and building cross-functional relationships requires even more intention because of the sheer number of stakeholders. You may be more specialized or work through more layers of management, but the same underlying transitions in how you think and lead still apply. Directors at large organizations may need an even greater emphasis on influence, coalition-building, and navigating ambiguity across business units, so as you read, consider how these shifts might scale in your context.

I’ll outline the key transitions on this path and what changes at each level. You need to broaden your focus from team to company and industry, extend your horizon from near-term delivery to long-term strategy, and adjust your definition of leadership as your scope grows. I’ll detail each shift so you’re ready for each step up.

What the roles actually look like

One important note before I describe these levels: I’m talking about a director of engineering, not a director of security, IT, data, or another domain. You can hold a director title in technology and manage a small team if you own a domain important to the company. In engineering at mid-sized or larger companies, a director usually manages managers and possibly a couple of very senior engineers.

A director of engineering is fundamentally execution-oriented. Your focus is your organization: are your teams delivering, what’s getting in the way, and how are your engineering managers doing? You were likely a line manager not long ago, and before that, perhaps a developer. Thus, your technical background remains focused, as your teams cover adjacent disciplines (e.g., Backend and Frontend). You’re thinking strategically, but mainly in the near term. Typically, your time horizon is six months to a year, since you are building on your manager’s strategy.

That’s not a criticism. The execution layer is essential. As a Director, you’re closer to the work than your manager. Organizations fall apart without people who are genuinely focused on delivery. But it does describe the ceiling of the role.

At the VP of engineering level, the shift is from looking down to looking around the company. You join the extended senior leadership team and work with cross-functional peers across the business. You now have visibility into the company’s longer-term direction. You’re expected to think at the system level, not just the team level. Your directors handle execution. Your job is to see how the pieces fit together and where they don’t. You have a wider technical scope because you are responsible for more disciplines. You’re thinking operationally, one to three years out.

Ask yourself: When was the last time you mapped dependencies across functions or business units? How often do you step back and assess how different teams’ plans might intersect or compete? Bringing this kind of diagnostic reflection into your routine helps you build the habits and perspective needed at the VP level.

The VP role also varies significantly depending on the company’s structure. In some organizations, a VPE reports to the CEO and effectively runs engineering day-to-day alongside a CTO co-founder who isn’t a management leader. In others, multiple VPs report to a CTO. The title means different things in different places, which is worth keeping in mind.

At the CTO level, your focus widens again, this time beyond the company. You think about how the company is executing and what technology can enable. You also watch the industry and your competitors, and track emerging trends that may matter in three to five years. You’re now a senior leadership team member. You contribute to the company strategy, not just align with it.

This outward focus is not just about scanning the horizon for interesting trends, but critically assessing risk and opportunity. For example, the emergence of generative AI has quickly expanded what is possible in product differentiation and introduced new security and ethical risks. Suddenly, companies face both the chance to leap ahead with innovative features and the risk of being disrupted by startups that build faster on these new technologies. Similarly, cybersecurity threats are evolving so rapidly today that your company’s market reputation and even core operations can be at stake if you are not looking ahead and shaping proactive responses. The CTO sees these shifts early and helps the company decide where to lean in, when to move cautiously, or when to double down.

When I moved into this level, I became responsible for areas I had never worked in directly: security, infrastructure, IT, data science, analytics, and internal finance and marketing systems. I had to learn enough about each area to lead well and make sure they had what they needed, even if I couldn’t do the work myself.

Across all three levels, your focus grows wider. You move from execution to operations, then strategy. Your technical scope grows broader, and your time horizon shifts from months to years.

How do you actually make the transition?

Here’s the thing about all of these transitions: you generally don’t get promoted to demonstrate them. You get promoted because you’ve already been demonstrating them. The title follows the behavior.

So, how do you start doing the next job before you have it?

Broadening your focus

If you’re an engineering manager or a director, your focus is naturally on your team. That’s appropriate. But if you want to move up, you need to start showing that you think beyond it.

Start by understanding how the people you work with daily actually do their jobs. How does product management decide what to include in the roadmap? How does UX approach a design problem? What does the QA team care about that your developers downplay? These are not just networking conversations. They give you real context for your decisions.

To put curiosity into action, turn this into a regular exercise. Set yourself a simple goal: once every week or two, schedule a lunch or coffee with someone outside of engineering: product, UX, QA, finance, or marketing; and ask them about their work and how it connects to the company’s goals. Treat it like an intentional challenge. Committing to scheduled conversations will build your understanding over time and help you develop a real cross-functional perspective, not just theoretical knowledge.

Then expand further. Take someone from finance to lunch and ask what accounts payable does and why it matters to the business. Ask a marketing person how they think about the customer. These conversations may seem unnecessary when you’re deep in delivery. But they help you build a picture of how the company works. That picture is what you need to help shape how it should work.

If there are cross-functional working groups or improvement efforts, volunteer for them. These tasks might feel like distractions, but they do two useful things. First, they give you exposure to people and processes you wouldn’t normally see. Second, they signal to your manager that you’re thinking beyond your own team. That signal matters.

The same goes for industry knowledge. Follow the trade press, podcasts, and industry blogs. It does not take long. If you want to join conversations about where the company fits in its market, you have to know what’s going on there. You need opinions you can back up.

Widening your orientation

Understanding your organization’s strategy is different from simply being aware of it. Most people hear the company’s goals at a town hall and think, “Okay, I understand the strategy.” That’s a start. But it’s not enough. Pause for a moment and ask yourself: how does my team’s work connect to that strategy? Does it connect cleanly? If not, how could it?

At Adobe, I led a team focused on heterogeneous computing, writing software to schedule signal-processing work across GPUs and CPUs. Our goal was to run as fast as possible on whatever hardware was available. This was deep, specialized work, very close to the metal. Then Adobe started moving to the cloud. Suddenly, that work was heading in a different direction from the company.

The easy move would have been to dig in. Cloud latency was terrible for our use case. Local hardware was better. I could have made that case. But instead, I asked: Could we treat the cloud as just another compute target? The latency was longer than the GPU bandwidth, but we controlled the cloud hardware. Maybe our scheduling system could be extended to handle it.

We started building a strategy around that alignment. People noticed. And I think one reason people started thinking of me as director-level was that I was actively considering the company’s direction, not just my team’s work.

You don’t need a perfectly polished strategy proposal every time. If you have an idea, bring it to your manager. If it’s not quite right, the conversation still helps. You learn why it doesn’t fit, which helps you develop better ideas. Having ideas and sharing them shows you’re thinking at that level.

Another part of broadening your orientation is understanding the system around you, not just the teams you manage. How does your team depend on other teams? What are the dependencies the other way? If you see two teams making heavy demands on a shared service team at the same time you need something, you can plan ahead. That kind of awareness: knowing constraints and relations between teams and using it to plan, is operational thinking. It’s VP-level thinking, even if you do it as a director.

Thinking longer term

Strategy is a skill, and like most skills, you get better at it by practicing it, not by reading about it.

Adobe had a training program for people on the cusp of the director level, and I was invited to join it. The whole program was focused on strategy because the leadership team understood that the gap between line managers and managers of managers is fundamentally about strategic thinking. Not technical skills, not management skills. Strategy.

If you want to develop that, start paying attention to what’s happening in your industry beyond your company. Not just as general awareness, but with opinions attached. Right now, everyone is having conversations about AI. What do you actually think about it? What are the constraints? What are the realistic applications for your company in the next six months? In the next two years? You don’t need to have it figured out. But if you can have a substantive, informed conversation with your manager about where you think things are headed and why, that demonstrates extended strategic thinking.

To put this into practice, try this assignment: This week, write a 200-word point of view on how AI might impact your product or your company. Consider the opportunities, risks, and whether you think it’s important for your team to start experimenting or learning now. Treat it as a draft and share your perspective with a peer or your manager to start a real conversation. The point is not to have the perfect answer, but to actively build the habit of strategic thinking by applying it to real, current topics. Over time, these bite-sized exercises will help expand your strategic thinking.

Broadening your technical knowledge

Your technical breadth expands naturally as you become responsible for more disciplines, whether you like it or not. The question is whether you engage with that expansion or manage it from a distance.

I’ve talked in previous articles about why you should lean into learning the technologies you become responsible for. You don’t have to become an expert. The goal is to understand them well enough to have a real conversation with the people who do them every day, to ask questions that aren’t too far off base, and to make them feel heard and understood. That trust matters a lot when you’re leading teams you didn’t come from.

One practical way to accelerate this process is to look for your own knowledge gaps actively. Start by asking yourself some basic self-reflection questions: Which technical areas do I find myself avoiding in meetings? Where do I rely most on others to summarize or interpret? Do I feel less confident discussing certain projects or systems in my team’s portfolio? Listing out these areas can help pinpoint blind spots that deserve attention.

You can also ask trusted peers or team leads for feedback: “Are there technical domains where you think my understanding is weaker?” or “What topics do you wish I engaged with more directly?” This can bring new perspectives to your self-assessment and highlight areas that may not be obvious to you. Knowing exactly where your knowledge is thin lets you focus your learning more efficiently and show your team you are committed to truly understanding their world.

A few other ways to do this: talk to peers who are responsible for disciplines you aren’t. Ask what it’s like to manage a data engineering team. What does that work look like? What are the common failure modes? If it’s possible to sit in on a planning meeting for a team outside your area, ask. Just say you’re interested and want to learn. They might say no, and that’s fine, but if they say yes, you learn something real.

Side projects are another way I’ve learned new things over the years. I’m not trying to become an expert. I’m trying to gain enough hands-on experience so I can follow a conversation with an expert, understand what they’re saying, and ask follow-up questions that make sense. That’s a reasonable bar, and it’s usually achievable with a few weekends of tinkering.

If you’re the mentor

Everything I’ve described above is also a set of things you can actively create for the people who work for you, if you’re a VP or CTO.

Start by identifying potential. The signals are usually pretty visible once you know what to look for. People who are curious about things beyond their immediate responsibilities. The people who are already thinking about how their work connects to the company’s direction. The people who volunteer for things, ask questions in cross-functional meetings, or come to you with ideas that go beyond their job description. Those are the people who are already thinking in the ways that lead to more senior leadership.

One practical way to make this potential-spotting more deliberate is to set aside 30 minutes each month for a quick review of your team. Ask yourself: who has shown these signals recently? Who has stepped up or shown interest in broader company goals? By making this a recurring part of your calendar, you turn talent recognition from an ad hoc practice into an ongoing development discipline. Over time, this habit will help you turn signals into real growth opportunities for the people ready to take the next step.

Once you’ve identified these folks in your team, delegate real work to them. Not just tasks, but ownership of things that require the kind of thinking you want them to develop.

The best example from my own career happened at Spotify. I was a VP reporting to the CTO when we decided the company needed an engineering career ladder. We’d never had one. The CTO delegated that project to me and supported me through it. I had to work across the entire technology organization, design something that would work for hundreds of engineers in very different specializations, get buy-in from leaders I’d never met, and partner heavily with HR, not just my HR business partner, but the CHRO, the compensation team, and the HRIS team. It was genuinely hard. And I learned more from it than from most of the work that was actually in my job description.

Did he delegate it because he wanted to develop me? Maybe. Did he delegate it because he didn’t want to deal with it himself? Also possible. Honestly, either way, it worked. I’ve built engineering career ladders at every company I’ve been at since then, and I delegate it every time.

The point is that there are many things you do as a leader that require exactly the kind of thinking you want to develop in your direct reports. Handing them ownership of those things, with your support, is one of the most effective ways to grow them.

Beyond delegation, explain your thinking. In your staff meetings, don’t just announce decisions; explain them. This matters for a few reasons. First, it helps people understand and support what you’re doing. But more importantly, it gives them the reasoning, not just the conclusion. A decision you announce in five minutes might represent thirty hours of meetings, months of context, and a dozen competing considerations. When you announce it, people get the output. When you explain it, they get the thinking. That’s what lets them make good decisions on their own when a similar problem comes up, instead of just pattern-matching on what you did. To make this easier, try using a straightforward lead-in like, “Here’s the trade-off I wrestled with…” or, “The key constraint I was weighing was…” This kind of sentence opener helps you quickly bring others into your thought process and gives your team a template for sharing their own reasoning when they make decisions.

Beyond explanation, be as transparent as you can. As you move into senior leadership, you accumulate a lot of information you can’t share. That creates a gravitational pull toward sharing less by default, because it’s easier to say nothing than to figure out what to share. I try to resist that. I stay careful about what I actually can’t share, and then I share everything else. The people who work for me make better decisions when they have context, and they understand my actions better when they know what I’m thinking. The alternative is that what I do looks random or arbitrary because I’ve withheld the information that would make it make sense.

Create opportunities for people to expand their thinking, separate from delegation. If someone volunteers for cross-functional work, support it. If that kind of work doesn’t exist yet, create it. Organizational improvement efforts, working groups, task forces, whatever form makes sense in your company. Don’t assume HR or someone else will generate these opportunities. You can create them yourself for your organization.

Give feedback that’s calibrated to the next level, not just the current one. If a director does good work, tell them. Then add what a VP would have done differently in that situation. Not as criticism, but as a way to help them see what growth looks like from where they’re standing. Most people don’t have a clear picture of what the next level actually expects of them. You can give them that picture through the feedback you provide over time.

For example, after a successful project delivery, you might say, “Great job keeping the team focused and delivering on time. At the VP level, I’d expect you also to anticipate cross-team dependencies earlier and proactively align timelines across groups to minimize bottlenecks. How would you approach that next time?” Or when they handle an incident well, you could note, “You communicated clearly with your team and resolved the immediate issue. A VP would also consider which system-wide process or coordination could help other teams avoid similar problems in the future. What broader fixes do you see here?” Specific feedback like this helps people step into the mindset of more senior roles before they get there.

Why this matters

When I look back at my career, the projects I’m proudest of aren’t the ones that lasted. The heterogeneous computing work at Adobe was genuinely interesting and technically hard, and it’s completely obsolete now. Technology moved on. You don’t need software to schedule GPU work the way we used to anymore. I’m proud of what that team built, but the work itself is gone.

What hasn’t faded is watching someone who worked for me post on LinkedIn that they’re starting a new role as a CTO or VPE. That lands differently. The idea that I played some part in helping that person get there, that’s a more direct and lasting impact than anything I’ve shipped.

And the thing about developing people is that it compounds. They’ll go on to support the next generation of leaders behind them. The influence extends well past the moment.

So if you’re on this path, that’s what’s on the other side of it. For the people following the path: keep going. It’s a hard job and a genuinely great one. For the people who are further along and mentoring, the most important work you do might not show up in a product release. It might show up years later in someone else’s announcement.

To hear an extended discussion of this topic, please listen to my recent podcast episode: The Director to CTO Path: How to Follow It, or How to Mentor It.

Originally published in my newsletter.

Talking to Executives: That’s Not a Derailment, That’s the Meeting

Why being understood matters more than being right

Seattle, USA – Photo by Kevin Goldsmith – February 2026

When I was starting out at Microsoft, I nearly derailed my first executive presentation over the word “avatar.”

We were building virtual world software, and I used “avatar” the way the industry did. The VP stopped me, insisting it wasn’t the right term based on its dictionary definition. I pushed back, stating it was accepted industry usage, and asked to move forward. He agreed, but became distant for the rest of the presentation.

Afterward, my boss’s boss pulled me aside. “If the VP wants to talk about a word, that’s what you talk about.” I was never invited to present to that VP again.

I was two years out of university. It was a painful lesson.

I’ve made a lot of mistakes in executive communication over the years, and I’ve been on both sides of that table long enough to understand why they happen. Before I was someone people presented to, I was terrified of the same thing. When I started at Adobe, my director was in San Jose while I was in Seattle. I’d see him present to the broader organization occasionally, but the first time he called me directly, I nearly froze. He just had a question about something, but I picked up the phone, heard his voice, and thought: “I’m talking to the director.” It felt enormous and scary.

I also know what it feels like to be on the receiving end of that anxiety. A few years later at Adobe, I was now a Director. A team that joined my organization set up a meeting to introduce themselves when I visited their office. I came to the conference room expecting to sit around the table and talk. Instead, I walked in to find a polished deck waiting for me, the whole team lined up, ready to present. It was the first time anyone had ever built a slide deck just for me. I felt guilty, honestly, because it was obvious they’d spent serious time on it, and I had just breezed in thinking we’d hang out. I understood immediately why they’d done it. But I also wanted to tell them: I’m just Kevin. You don’t have to do this.

The key: Executives are just people with different responsibilities. The anxiety you feel walking into that room is completely understandable, and mostly unnecessary.

What I learned the hard way from that Microsoft VP is that when you speak to executives, every word carries weight. The core tension is that you are closer to the work than they are. You’re the expert in your domain. But that doesn’t make you the expert in the room. You’re there because the thing you’re working on matters to them, not necessarily in the way it matters to you. Executives have the broader business context. You have the deeper technical context. They’re optimizing for risk, clarity, and decision making, not technical elegance.

Executives aren’t there to hear your whole presentation. They’re there to get something specific, and that something is usually part of a much larger set of conversations they’re having. If you give them a complete tour of your work and none of it is what they came for, they’ll interrupt you. Or they’ll check email. Or they’ll leave. Not out of disrespect, but because they have other things to do, and this meeting didn’t give them what they needed.

A framework: the four C’s

Before any executive communication, whether it’s a meeting, an email, or a Slack message, run through four questions.

Clarity. Are you using language that cannot be misinterpreted? Not your team’s language, not industry jargon. Plain language. Define terms the moment you use them, or don’t use them at all.

Context. Have you situated your topic inside the broader business picture, as best you understand it? You won’t have all their context. That’s fine. Show that you’re thinking past the narrow scope of your project. The executive you’re talking to is probably thinking about two other projects and how yours intersects with them. Meet them there as best as you can.

Consequence. Have you made it clear what happens if a decision is made or not made? Don’t assume the stakes are obvious. Say something like: “If we get the help we need, I’d put our odds of delivering on time at 70%. Without it, 30%.” That gives them something to act on. They’re not going to intuit the downstream implications of your team’s situation. You have to surface them.

Control. Are you demonstrating command of your subject, including its risks and trade-offs? Executives have usually been where you are. They can tell when someone is leaving something out, whether intentionally or because they haven’t thought it through. Either reading is bad for you.

If you skip answering one of these four questions, they’ll go hunting for the answer. That’s when the interruptions start and when you lose control of the room.

Calibrating your technical level

One common challenge in executive settings is explaining topics at the right level of technical detail for your audience. This challenge is called technical calibration: making sure your explanations match what your audience understands and needs, not just what is technically accurate.

Overexplaining occurs when you dive deeply into technical details with an audience that lacks the same technical background or expertise. For example, if you are a developer or a frontline engineering manager presenting to a mixed-background group, most will not be technical. If you go straight to implementation specifics without first gauging your audience’s familiarity, you risk losing them. I have seen this happen when I wanted to give team members exposure to the executive team. Despite my advice to focus on the business context, they presented too much technical detail. As a result, my peers disengaged—not out of disrespect, but because the level of information wasn’t appropriate for them. It can be tough to watch, especially knowing how much effort goes into preparing.

Under-explaining happens when you assume the audience shares your technical context and use unexplained terms or reference internal systems without clarification. Under-explaining can make your message opaque to executives, even if they don’t say so. Executives may not interrupt to ask, but will quietly disengage if they can’t follow the discussion. Clear technical calibration helps prevent this by defining terms and providing just enough context.

To technically calibrate, start by identifying your audience’s background and what matters to them. Focus your explanation on three areas: business impact, customer impact, and risk. These areas matter most to executives. Lead with what changes, who is affected, and what costs or risks are involved. Offer more technical details if requested, but always start with a clear context relevant to your audience’s familiarity.

Here’s something worth understanding about the translation problem. As a CTO, my job is to make complex technical realities legible to people who don’t live in technology. My peers on the executive team understand the broad strokes of engineering, but they’re not going to track a detailed architectural discussion, nor should they. I continuously hear fairly complicated things from people on my team, figure out what’s actually important in a business context, and translate them for my peers. That skill didn’t come naturally. I developed it by presenting to executives over the years and paying attention to what landed and what didn’t.

If you’re looking to move into senior technical leadership, this is not optional. The ability to translate your domain for non-technical peers is one of the most critical skills you can develop. In the first years of my career, I thought being technically correct was sufficient. What I eventually learned is that clarity and alignment matter more than precision. You can be right about everything and still fail to move anything if the people you’re talking to can’t follow you.

How to handle the room

A few more things worth knowing.

Lead with the conclusion. In written communication, especially, I see people bury the point. They walk me through everything that happened before telling me why they’re writing. Put the conclusion first. We have this problem. Here’s what I need. The background can follow, if I need it.

Plan to use half your time. If you’re given an hour, prepare for thirty minutes. You will get interrupted. Questions will go deep. Tangents will happen. If you’re done in half an hour and could have taken an hour, that’s a great outcome. It means you were clear and direct, leaving room for the conversation to go where it needed to. The executives you are presenting to will appreciate your brevity if it gives them time back in their day.

Say “I don’t know” when you don’t know. This is harder than it sounds. You’re in front of people who matter, and someone asks a question you can’t answer. The instinct is to approximate, to say it’s going pretty well, to give them something. Resist that. If you guess and you’re wrong, the next time they hear about your project from someone with the real information, they’ll wonder whether you were confused or covering something up. It’s more important for you to protect your credibility than your ego. If you don’t have an answer, commit to providing one as soon as possible after the meeting.

Treat interruptions as signals. If someone goes deep on something you considered minor, or starts a side conversation with the person next to them, that’s not a sign things are going badly. Something you said connected to a concern you’re not aware of. Stay with it. Follow it. Don’t try to reroute back to your slides. I’ve made this mistake. The executives started talking among themselves because something I’d said triggered a prior discussion. At a certain point, I was just standing at the front of the room waiting. I tried to bring them back because I was worried about running out of time. They didn’t have it. We ran out of time anyway. The deck got a “just send it over, sorry we ran out of time.” That is a common outcome from one of these meetings. Remember: your job in the room isn’t to get through your material at all costs—it’s to meet executives where they are and help them move things forward. If you do that, you’ve succeeded, even if the meeting doesn’t go as planned.

Executive brevity isn’t disinterest. Senior leaders in large companies can spend eight hours in meetings a day. They get direct because directness is how you survive that schedule. If they’re short with you, it probably just means they’re operating efficiently. Don’t confuse it with dismissal.

The view from the other side

Now that I’m regularly on the other side of these conversations, I recognize pretty quickly when someone is protecting their ego instead of informing me. When they get defensive about a challenge, when they oversell, when they’re more focused on how they look than on what I actually need to understand. And I recognize the opposite, too. When someone says, “I don’t know, but I’ll find out,” I trust them more, not less. When someone slows down and clarifies rather than powering through, I appreciate it.

What executives want from anyone presenting to them is to help them understand something so they can make a good decision. That’s it. You are not there to demonstrate your expertise. They already assume you have it. That’s why you’re in the room. You’re there to enable good decisions for the people you’re talking to.

Every word should either reduce ambiguity, increase alignment, or surface risk. Remember, every executive conversation is a chance to build trust and influence outcomes. Treat each as an opportunity to connect, learn, and shape direction.

Ask yourself one question before every executive interaction: Am I optimizing to be right, or am I optimizing to be understood?

The answer should always be the latter.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Talking to Executives: That’s Not a Derailment, That’s the Meeting.

Originally published in my newsletter

The Shift to Managing Managers

From managing work to managing context

Vancouver, Canada – Photo by Kevin Goldsmith – February 2026

One of the most abrupt transitions in a leadership career is the moment you stop managing a team and start managing managers.

It rarely happens gradually. One day, you lead a small group and their output. The next, you oversee an organization whose work you can’t directly touch. You can study, prepare, and talk to experienced peers, but most learning comes the hard way.

What makes this transition particularly tricky is that the behaviors that got you here often stop working once you arrive.

When you manage a team, being close to the work is an asset. When you manage managers, that same instinct quietly becomes a liability.

The real tension: leverage versus comfort

People often frame this as a choice between autonomy and control. That’s partly true, but not the core issue.

The deeper tension is leverage versus comfort.

Staying close to execution feels safe. You know what’s happening. You can catch issues early. You feel accountable in a very tangible way. When something goes wrong, you can point to where you were involved and how you tried to prevent it.

The problem is that this sense of responsibility doesn’t scale.

As your organization grows, your job requires a different orientation. You need to look outward and sideways, not just downward. You need to understand the business direction, align with peers, and identify organizational risks before they become visible problems. None of that happens if your attention is consumed by team-level decisions.

Managing managers isn’t really about getting closer to the work. It’s about being clearer about what the work actually is.

How over-involvement erodes ownership

When leaders stay too focused on the layer below them, the effects show up quickly.

The managers reporting to you lose ownership because you’re implicitly taking it away from them. If you’re paying more attention to their teams than to them, they stop behaving like leaders and start behaving like intermediaries. They wait. They escalate. They defer.

At the same time, you become a decision-making bottleneck. The fastest way to ensure decisions align with your thinking is to require approval. That works in the short term, and it feels responsible. But it trains the organization to route everything through you.

Once that happens, your leverage disappears.

You’re always busy, but the organization actually slows down because decisions wait for you instead of being made by those with the information.

Worse, your own growth stalls. You can’t take on a broader scope because you’re too essential to the current one.

Why context matters more than answers

Early in my management career, I was rewarded for being deeply involved. I worked hard to be a good manager, to support my team, and to fix problems directly. That approach produced results.

When I began managing larger groups, I kept using that approach, expecting it to work.

It didn’t.

My intent didn’t change, but the effect did. All the context lived with me: the business constraints, political realities, and broader trade-offs. My managers lacked that context. I failed to transfer my understanding.

Decisions slowed down. Some were simply wrong. And the surprises I got were coming from the wrong direction. Instead of hearing early warnings from teams, I was learning from peers that work had been duplicated, priorities had shifted, or entire initiatives had moved without us.

Managers don’t usually need more direction. They need better framing.

When people understand what their work means in the larger system, they make better decisions on their own. They know who to talk to. They know what to ignore. They don’t need you as a relay for every conversation.

If your managers need you for every decision, you don’t actually have a management team. You’ve built a relay where everything passes through you.

There is one relay role that is appropriate: translating senior leadership’s context into something your organization can act on. Being the relay for your own teams, or peer organizations, is not.

The shift in where your attention belongs

There are two directions mid-organization leaders can focus.

Looking down is about coaching, quality, consistency, and execution. You’re responsible for results, but no longer do the work. Your job is to ensure that your managers are capable and focused on the right things.

Looking around is about strategy, alignment, organizational dynamics, and external signals. This is where managers of managers add unique value. And this scope only increases as you move up.

At some point, your role shifts from decision-maker to context-setter, standard-setter, and sense-maker.

Autonomy doesn’t grow because someone has “earned it.” It grows because shared understanding exists.

Delegating decisions instead of tasks

One of the most common mistakes leaders make at this level is delegating tasks rather than decisions.

Task delegation keeps control with you. Decision delegation transfers ownership.

If managers bring you work to approve, you haven’t delegated. You’ve added a step. Permission makes you a bottleneck; reasoning makes you a coach.

A simple change helps: ask “why did you choose this?” instead of “what do you want to do?”

That question is neutral, non-confrontational, and incredibly revealing. It tells you how someone thinks, what information they used, and what trade-offs they considered. If their reasoning is weak, that’s a coaching moment. If it’s strong, you learn something.

Warning signs you’re overmanaging

Overmanagement has predictable symptoms.

Managers escalate decisions that clearly belong to them. You’re deeply involved in hiring, performance management, or prioritization well beyond what your role should require. People ask, “What should I do?” instead of “Here’s my thought.”

Work slows when you’re unavailable. Vacations create anxiety. Your calendar fills with internal reviews and status meetings. Teams schedule their work around your presence. When everything flows through you, things might work, but they only work while you’re there.

Feeling indispensable is not a success metric. It’s a warning sign.

If the system only works while you’re holding it together, you’ve capped both your organization’s growth and your own.

Resetting decision boundaries

If you recognize these patterns, the first step is acknowledging them. To yourself first, then explicitly with your managers.

Staying too close to execution limits their growth. It also quietly limits yours.

One tool I’ve found useful is making decision boundaries explicit. With each manager, define:

  • Decisions they should make without telling you.
  • Decisions they should make and inform you about.
  • Decisions they should consult you on before acting.
  • Decisions you will make together.

The specifics will vary by person and role. The important part is that expectations are clear at the decision level, not just the role level.

Over time, decisions should move steadily toward greater autonomy. That movement marks growth, builds trust, and reduces dependency.

Expect friction during the transition.

Stepping back doesn’t immediately make things better. It usually makes them messier first.

Decisions will be uneven. Managers will test boundaries. Two people will make different calls in similar situations. That inconsistency is uncomfortable, but it’s part of the calibration process.

Use one-on-ones to learn how decisions were made, not approve them. Ask about data, risks, and expected outcomes.

Sometimes you’ll realize they missed something important. Other times, you’ll realize they saw things you didn’t. Both outcomes are valuable.

Replace control with calibration.

What you’re actually building

Managers operate under pressure from their teams while lacking full information about the organization. New managers optimize for approval when leaders are hands-on. Experienced managers read close oversight as a lack of trust.

When context isn’t shared, people invent explanations for what they are seeing in the organization. Alignment drifts. Culture debt accumulates.

Prevent this by making the invisible visible. Share what you hear, explain trade-offs, talk about constraints, and show how decisions connect.

If you do this well, work won’t pause when you step away. Decisions will improve because they’re made closer to the work with better context than you could ever have alone.

Scaling leadership means building teams that make informed, independent decisions and create lasting impact beyond your presence. Transitioning from managing work to managing context is essential for real organizational growth.

To hear an extended discussion of this topic, please listen to my podcast episode: The Shift to Managing Managers.

Some helpful references and tools related to Managing Managers:

  • “Using Agile Techniques to Build a More Inclusive Team” – In this talk, I explain an exercise I use with the managers who report to me to help establish a mutually agreed-upon framework for who makes what decisions.

Originally published at https://kevingoldsmith.substack.com/p/the-shift-to-managing-managers

Leading What You’ve Never Done Before

What happens when your role outgrows your technical background

Tokyo, Japan – Photo by Kevin Goldsmith – January, 2026


One of the guarantees of career progression in technology leadership is that, eventually, you will outrun your own resume.

Most technology leaders start as specialists. Frontend, backend, SRE, QA, mobile, data. Your first leadership role is often managing a team you used to be on, doing work you understand deeply. That familiarity is comforting. It’s also temporary.

As your scope grows, you start owning work you’ve never done yourself. A backend lead suddenly finds themselves managing frontend teams. An application developer finds themselves responsible for mobile, infrastructure, data, or security. Eventually, the gap widens enough to feel genuinely uncomfortable.

That discomfort is normal. It’s also where many leaders get stuck.

Early in my management career, I felt that pressure acutely. I had spent years as a C++ application developer. That expertise was my credibility. When I found myself responsible for iOS clients, Ruby backends, and systems I didn’t know well, I worried that I was no longer qualified to make decisions or lead effectively.

My instinct was to compensate by trying to learn everything. I wanted to stay technically credible in every domain I owned.

That instinct turned out to be the wrong one.

The trap of technical credibility

As leaders, we often confuse credibility with expertise. We assume that to lead an area, we need to be the smartest person in the room about it. That might work when you’re leading a single team in a domain you know well. It breaks down quickly as your scope expands.

If you try to become an expert in every system your organization owns, you slow everything down. Worse, you undermine the people you hired to be experts. You become a bottleneck without realizing it.

The opposite mistake is just as damaging. Some leaders disengage entirely from unfamiliar domains. “I don’t know that area, so I’ll just trust the team and focus on what I know.” That signals disinterest, even if you don’t intend it to. Teams notice. Motivation drops. Accountability weakens. And you’re still responsible when things go wrong.

Neither extreme works.

The real challenge isn’t a lack of knowledge. It’s understanding how your role changes as your scope grows.

How leadership actually shifts

There’s a progression most leaders have to make, whether they realize it or not:

You start by doing the work.
Then you review the work.
Then you design how the work gets done.
Eventually, you design the system that produces good decisions.

When you’re leading areas you’ve never worked in, your role moves firmly into those last two stages. You are no longer there to solve problems directly. You’re there to make sure the right problems are being solved, in the right way, by the right people.

That shift is uncomfortable if your identity is still tied to being a strong individual contributor. But it’s unavoidable if you want to lead at scale.

Failures at senior levels rarely stem from a lack of subject-matter expertise. They come from unclear ownership, misaligned incentives, poor decision-making systems, and leaders who stop being curious about the parts of the organization they don’t personally understand.

What to focus on instead

You don’t need deep expertise in every domain you own. You do need a solid mental model.

That means understanding the vocabulary, incentives, constraints, and common failure modes. It means being able to follow the conversation, ask good questions, and recognize when something doesn’t quite add up.

The questions that matter at scale are remarkably consistent, regardless of domain:

  • What does “good” look like here, and who decides?
  • What happens if this fails?
  • What risks are we knowingly accepting?
  • Are we relying on heroics?
  • How do problems surface early?

Those questions don’t require you to know the implementation details. They require judgment, context, and experience. That’s the transferable part of your background.

Your job is to let specialists own the “how,” while you own the “why” and the “so what.” When you provide clear context and intent, good teams make better decisions on their own.

Things you have to stop doing

Leading unfamiliar domains also requires unlearning some habits.

You have to stop pretending to be the smartest person in the room. Your job is to hire people who are better than you at their craft and give them room to do it well.

You have to stop asking detailed technical questions just to mask uncertainty. People can tell when you’re doing it, and it erodes trust rather than building it.

You have to stop measuring success only through artifacts and dashboards. As you move up, outcomes matter more than outputs. Metrics are signals, not substitutes for understanding.

Trust without abdication

Trusting domain experts doesn’t mean stepping away. It means staying engaged without micromanaging.

You are still accountable. You still ask questions. You still challenge assumptions. But you don’t make decisions for teams in areas where they clearly know more than you do.

You also have to create space for people to disagree with you. Role power makes that harder than most leaders realize. When you suggest something, people often hear a decision. If you don’t actively invite dissent, you lose valuable signal.

That matters even more when you’re not the expert.

The long view

Over time, leading unfamiliar domains gets easier. Not because you become an expert in everything, but because you get better at learning just enough, asking better questions, and building trust with the people who know the details.

Progression doesn’t mean abandoning your technical background. It means extracting the lessons from it and applying them at a different level.

If you’re feeling exposed because you’re leading something you’ve never done before, that’s not a sign you’re failing. It’s usually a sign that your role has changed faster than your self-image has caught up.

That gap is uncomfortable. It’s also where real leadership growth tends to happen.

To hear an extended discussion of this topic, please listen to my podcast episode: Leading What You’ve Never Done Before.

Originally published in the It Depends: Lessons in Technology Leadership newsletter at https://kevingoldsmith.substack.com/p/leading-what-youve-never-done-before

Reflection is a Crucial Leadership Skill

Kyoto, Japan – Photo by Kevin Goldsmith – December, 2025

At the start of every year, leaders are encouraged to look back and look forward. Most of us nod along, then immediately get pulled back into execution. Meetings stack up, priorities collide, and the reflection part quietly disappears.

That’s a mistake.

Reflection isn’t something you do when you have spare time. It’s what keeps you effective once the job starts to feel familiar.

I’ve been a CTO for about a decade now. One of the things experience gives you is comfort. You’ve seen the patterns before. You know how most situations play out. You can shortcut decisions that used to require real thought. That’s valuable. It’s also dangerous.

Comfort is where growth quietly stalls.

Why reflection gets harder as you get more senior

Early in your career, learning is unavoidable. Everything is new. You make mistakes constantly, and the feedback is often immediate. Over time, that changes. As you move into senior roles, especially at the executive level, feedback drops off sharply.

The expectation is that you already know how to do the job. That is why the company hired you.

You don’t really have peers at your company who do the same work you do. Your manager doesn’t focus on developing you. They don’t have the time. And if things are mostly working, no one is pushing you to examine how you’re operating.

That’s exactly when reflection matters most.

Without it, success turns into habit. Habits turn into autopilot. And autopilot is where you stop asking why.

The more senior you are, the more your blind spots matter. If you don’t have a structured way to surface them, you don’t even know what you’re missing.

Reflection is what makes you less busy

When I talk about my reflection process, the most common response I hear is, “That sounds useful, but I’m too busy.”

I get it. Blocking half a day, or even a full day, feels indulgent when your calendar is already full.

But reflection isn’t what makes you busy. It’s what makes you effective.

Stephen Covey called this “sharpening the saw.” Spending time improving how you work reduces the total effort required to do the work. When you skip reflection, you don’t save time. You push the cost downstream, usually onto your team.

If you’re helping your team plan their year, but you’ve never planned your own, that imbalance shows up in your decisions.

Growth doesn’t happen by accident

Earlier in my career, I didn’t reflect much at all. I was moving fast, learning on the job, and things seemed to be working. So I kept going.

Eventually, things stopped working as effortlessly as they used to.

The approaches that got me to one level weren’t enough to get me past it. I had leveled out without realizing it, and I didn’t have the tools to understand why. That’s when I started reading more deliberately, working with a coach, and learning from peers and mentors who already treated reflection as part of the job.

That shift changed how I approach new challenges. I stopped seeing them as interruptions and started treating them as learning opportunities. When things don’t work now, I don’t just move on. I try to understand what happened and what to adjust next time. When things are working well, I take a bit of time to understand why they are working and how I can apply those lessons in other areas.

That habit is what has kept me from topping out again.

Structure matters more than the exact process

I’m not naturally a journaler. I tried. It didn’t stick. What worked for me was creating a structured reflection process that removed friction.

Today, mine has a few layers:

Twice a year, I step back for a personal strategy offsite. I assess the last six months and set priorities for the next six. That takes about a day.

From that, I set quarterly goals. Small, focused things I want to work on in the next quarter.

Each month, I do a short review to revisit those goals and see what’s tracking and what isn’t.

Every week, usually on Sunday night, I look back at the prior week and ahead to the next one. What worked? What didn’t? What do I want to do differently?

You don’t need all of this. You might only do a monthly or weekly reflection. The specifics matter far less than having some regular practice.

The point isn’t rigidity. It’s structured flexibility.

Like good software development, this isn’t a waterfall plan. It’s a set of goals that’s tested against reality week by week and adjusted as conditions change.

The practice matters more than the plan

Over time, I’ve learned that the practice itself is more important than any individual insight. Some weeks, nothing profound comes out of reflection. That’s fine. The value is in consistently creating space to think.

When I stop doing it, I notice quickly. Decisions get sloppier. My calendar fills with other people’s priorities. I become busy without being intentional.

When I return to the practice, it gets easier again.

And your team notices. They can tell when you’re reflective and when you’re not. When you’re willing to say, “This isn’t working, let’s change it,” you’re modeling the behavior you want from them. You’re showing that thinking matters more than mindlessly following a plan.

You can’t expect deliberateness from your team if you don’t practice it yourself.

Start small, but start deliberately

If you’ve never done this before, don’t copy my process. I didn’t start here either.

Block a few hours. Use a simple reflection exercise. Borrow someone else’s structure. Ask yourself:

  • What’s working well?
  • What isn’t?
  • What should I try doing differently?

That’s enough to begin.

If you already have a process, reflect on it. Is it still helping? Or are you just going through the motions? If it isn’t working anymore, change it.

The goal isn’t perfection. It’s deliberateness.

Busy on purpose beats busy by default.

Final thought

You can’t lead others to grow if you’ve stopped growing yourself.

Reflection isn’t optional. It’s what keeps you sharp, adaptive, and intentional—especially once the job starts to feel easy.

The best leaders aren’t the ones who have it all figured out. They’re the ones who keep asking better questions.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Success Makes You Dangerous: Why Comfortable Leaders Stop Growing.

Originally published at https://kevingoldsmith.substack.com/p/reflection-is-a-leadership-skill

Process Is a Tool, Not a Virtue

Tokyo, Japan – Photo by Kevin Goldsmith – December 2025

Process is one of those topics that reliably creates tension in growing engineering organizations. Too little of it and everything feels chaotic. Too much of it and nothing moves. Most teams I work with aren’t confused about whether process matters. They’re struggling with when to add it, how much to add, and how to tell when it’s gone too far.

Process is almost always introduced as a solution to a problem. What’s less obvious is that process also creates its own problems. Every new rule, gate, or ceremony adds coordination overhead. Sometimes that overhead is worth it. Sometimes it quietly becomes the thing slowing you down.

The hard part isn’t deciding whether you need a new process. It’s understanding what problem you’re actually trying to solve.

Why Process Exists (and Why It Backfires)

At its core, process exists to solve coordination problems.

When there’s too little process, you see the same patterns repeat:

  • Teams duplicate work.
  • Ownership is unclear.
  • Quality varies wildly.
  • Decisions get revisited because there’s no shared understanding.
  • Production systems break in ways no one anticipated.

In small teams, this can be survivable. People talk. They improvise. They find and fix problems quickly. But as the organization grows, informal coordination stops scaling. You can’t rely on hallway conversations once dozens of teams are working in parallel.

That’s where process starts to help.

The failure mode comes when a process is copied wholesale from larger organizations or added reflexively in response to a single incident. What speeds up a 10,000-person company will slow a 500-person company to a crawl, and it can completely stall a 100-person startup.

A process that doesn’t match your size, culture, or problems doesn’t just fail to help; it actually harms. It actively makes things worse.

The Real Question Leaders Should Ask

The question isn’t “Do we need more process?”

The real question is: What coordination problem are we trying to solve, and what is the lightest-weight way to solve it?

Leaders tend to get this wrong in two predictable ways.

Some avoid adding process entirely, trying to preserve a sense of scrappiness long after the organization has outgrown it. Things that used to work stop working, but no one wants to acknowledge that the context has changed.

Others swing too far in the opposite direction, importing big-company processes because “that’s how it’s done at scale.” The result is unnecessary gates, approvals, and bottlenecks that strip teams of autonomy without actually improving outcomes.

Both paths lead to frustration, just for different reasons.

Process Is a Choice About Autonomy

Every process decision is a decision about autonomy.

Good processes increase autonomy by clarifying boundaries, reducing surprises, and preventing rework. Bad processes reduce autonomy by adding gatekeepers, slowing decision-making, and centralizing control.

A simple test helps here: Does this process let teams move faster, or does it make them wait on someone else?

Code review is a good example. Lightweight reviews prevent production issues and enable teams to move faster with confidence. Mandatory review meetings that require everyone to wait for a calendar slot are a very different thing. Same intent. Very different outcome.

A Simple Process Evolution Cycle

Over time, I’ve found it helpful to think about process in three phases.

First: chaos signals.

You don’t add process because it feels right. You add it because you’re seeing repeated friction—across teams, not just in one place. Rework, unclear ownership, inconsistent quality, inter-team conflict, and recurring bottlenecks are all signals worth paying attention to.

Be careful here. A disagreement between two people is not a process problem. Solving a people issue with an organization-wide process is one of the fastest ways to create unnecessary drag. Similarly, repeated friction between the same two teams may be more indicative of an organizational structure issue rather than a lack of process.

Second: deliberate addition.

Add the minimum process required to solve the specific coordination problem you’ve identified. Design it to enable autonomy, not replace it. And treat it as an experiment, not a permanent fixture.

Every bit of process takes away some autonomy by design. The goal is to take away as little as possible while still solving the problem.

Feel free to learn from other companies’ processes, but ensure the components you implement are scaled to your organization’s size and the problem you are trying to address, and aligned with your culture.

Third: monitoring and pruning.

Process ages. What helped at 50 people often slows you down at 200. What worked at 200 creates friction at 500.

If you aren’t actively removing processes, you’re accumulating them. Regular retrospectives, not just within teams, but across projects and the organization, are one of the best ways to surface what processes are no longer pulling their weight.

If a process no longer serves you, remove it. Don’t keep it out of habit.

One Practical Example

One lightweight process I’ve used successfully in multiple organizations addresses a common bottleneck: cross-team changes.

Team A is working on a feature or fix that requires a change in code that Team B is responsible for. Instead of Team A filing a ticket and waiting weeks for Team B to prioritize and make the change, Team A makes the change itself. Team A notifies Team B of their intent, in case there are important gotchas they should be aware of. Team A submits a pull request, and Team B reviews it. Once merged, ownership of the new code transfers to Team B.

The result is fewer queues, faster delivery, and greater transparency in accountability, with very little added overhead. Same coordination problem. A very different solution from a backlog and a waiting line. This straightforward process helped one of my organizations avoid a new heavyweight quarterly planning process (so many meetings!), which was proposed to address increasing cross-team dependencies

How Process Goes Wrong

Most process failures fall into a few buckets:

  • Copying another company’s process wholesale.
  • Using process to compensate for poor communication or a lack of trust.
  • Adding controls to feel safer after an incident, without considering the cost.
  • Creating a process for the whole organization to address friction between two individuals or teams,
  • Never revisiting what you’ve added.

In the incident example, leaders sometimes add new processes in response to unexpected fragility, which leaves them fearful about what else they do not know. Process as fear-driven control kills speed and erodes trust. Guardrails like automation, testing, and monitoring usually achieve better outcomes with less friction.

Bringing People Along

People tolerate a new process when they understand the problem it solves.

Be explicit about the why. Involve teams in the design. Ask for the lightest-weight solution. And commit publicly to revisiting it. Most teams are willing to try something if they know they won’t keep living with it if it doesn’t work.

The fastest way to create resistance is to impose a decree from above without context.

The Point Isn’t Less Process

Early in my career, I thought that process was the enemy of speed. Experience taught me something more nuanced.

Process isn’t good or bad. It’s a tool. And like any tool, it has to fit the problem.

Clear ownership boundaries can increase freedom. Lightweight coordination can make teams faster. Thoughtful pruning can restore momentum that’s been quietly lost.

The goal isn’t less process. The goal is fit-for-purpose processes, deliberately added, designed to protect autonomy, and removed when they stop helping.

That’s how you scale without losing what made your team effective in the first place.

To hear an extended discussion of this topic, please listen to my podcast episode: The Right Amount of Process: Finding the Balance Between Chaos and Bureaucracy

Originally published in my newsletter at https://kevingoldsmith.substack.com/p/process-is-a-tool-not-a-virtue

Tech Debt Is a Signal, Not a Sin

What tech debt actually tells you about your team and your system

Miami Beach, USA – Photo by Kevin Goldsmith – December 2025

Tech debt comes up constantly: in mentoring conversations, consulting work, conference Q&A, and inside my own teams. I’m always a little surprised by how often it’s treated as a moral failure rather than what it usually is: a set of trade-offs made under real constraints.

That framing matters because tech debt isn’t inherently good or bad. It’s a consequence of shipping. If you’re delivering real value, especially in an environment that values learning and iteration, you’re accumulating debt all the time. Every line of code you ship today is tomorrow’s constraint.

The question isn’t whether you have tech debt. The question is whether you understand why it exists and what it’s doing to your system.

Early in my career, I thought tech debt meant someone made a bad decision. Experience taught me otherwise. Some debt is deliberate. Some is benign. Some is dangerous. And some isn’t really about code at all, it’s a signal that something upstream is broken.

Tech debt as a leadership problem

The real leadership tension around tech debt is that it all looks the same in a backlog. Engineering feels the pain and wants to fix it. Product wants to hit dates. Executives want predictable results. From the outside, “we need to spend three sprints on tech debt” just sounds like unpredictability.

I’ve lived this from both sides. Early in my career, after inheriting a large, aging codebase that was genuinely holding a company back, I swung too far in the other direction at my next startup. Determined not to repeat that experience, I over-architected for a future we hadn’t earned yet. We built systems for a five?year horizon when we were still trying to survive the next six months.

Eventually, reality caught up with us. The complexity slowed us down more than the hypothetical debt ever would have. The lesson stuck: avoiding tech debt at all costs can be just as damaging as ignoring it entirely. Both mistakes stem from treating tech debt as a moral rather than a contextual issue.

That tension exists because tech debt covers very different underlying realities. Deliberate shortcuts, accidental architectural drift, aging technology choices, and systemic organizational issues all surface the same way: as work engineers would like to do.

If you don’t distinguish between those causes, you’ll either fix the wrong things or fail to fix what actually matters.

Four kinds of tech debt

Over time, I’ve found it useful to think about tech debt through four lenses, based on intent and impact. This framing isn’t a framework so much as a way to avoid treating very different problems as if they were the same.

Pragmatic (intentional) debt. This is debt you take on by choice: because you’re validating an idea, avoiding premature optimization, or buying time to learn. Healthy teams do this constantly. It’s a sign of good judgment, not sloppiness. The failure mode here isn’t taking on the debt; it’s taking it on invisibly or failing to revisit the decision.

A helpful test is simple: did we understand the trade-off when we made it?

Required debt. This is debt that actively constrains the business: reliability issues, security risks, scalability limits, or architectural bottlenecks that slow delivery. This debt isn’t optional. Avoiding it just increases the eventual cost.

The key question here isn’t “does this bother engineers?” It’s “does this prevent the business from moving in a strategic direction?” If the answer is yes, and you can measure it, you have required work.

Incidental debt. Every mature codebase has code that isn’t pretty, isn’t modern, and isn’t fun to work on, but works reliably and is rarely touched. This debt is usually safe to ignore.

Refactoring something simply because you don’t like it is frustration, not strategy. The cost of touching stable code is often higher than the cost of living with it.

The question to ask is: is fixing this cheaper than leaving it alone?

Symptomatic debt. This is the most dangerous kind. It’s debt that keeps reappearing because of unclear strategy, constant priority shifts, fractured ownership, or organizations that leave no capacity for anything but delivery.

Fixing the code doesn’t fix the problem. The system that produced the debt will just generate more of it somewhere else.

Here, the real question is: what system is creating this debt?

Why teams get stuck

Most teams struggle because they treat all tech debt as equally urgent or equally ignorable. Neither is true. Only one of these categories demands immediate action. The rest require judgment, patience, or leadership intervention outside the codebase.

I’ve seen this play out repeatedly. A monolith that was absolutely the right choice for a small team slowly becomes a deployment bottleneck as the organization grows. What was once enabling starts constraining. The mistake isn’t the original decision—it’s failing to recognize when the context changed.

I’ve also seen the opposite: teams over-architecting far into the future, building complexity they don’t yet need, because they’re trying to avoid hypothetical debt five years out while ignoring the real problem six months away.

Both mistakes come from the same place: losing sight of intent.

Making better tech debt decisions

Treat tech debt decisions like any other strategic trade-off. They deserve the same level of judgment, visibility, and follow-through as product or organizational decisions. Make them deliberate, visible, and tied to business outcomes.

If you want support from product partners, executives, or peers, you must speak the language of impact. Reliability, cycle time, risk, and optionality are business concerns, not engineering preferences.

A few practical heuristics help:

  • Track intentional debt and revisit it deliberately.
  • Prioritize required debt alongside roadmap work, not as an afterthought.
  • Leave incidental debt alone unless it becomes chronic.
  • For symptomatic debt, stop coding and start examining structure, incentives, and capacity.

Mapping how work actually flows through your organization is often more revealing than reviewing the code. Consistent friction points usually point to systemic issues, not isolated mistakes.

The human layer

Most tech debt isn’t about code. It’s about pressure.

Engineers feel guilty about shortcuts unless leaders normalize intentional debt as a legitimate tool. Product partners need clarity that some debt is an investment in learning faster. Executives need visibility into which debt threatens outcomes and which doesn’t.

When leaders promise to revisit a debt decision, they have to follow through, even if the answer is still “we’re leaving it.” Broken promises push teams toward overbuilding today because they don’t trust tomorrow.

Teams under constant delivery pressure don’t accumulate debt because they lack skill. They do it because the system leaves them no alternative. Left unaddressed, that pressure undermines morale and code quality.

How to apply this tomorrow

You don’t need a multi?quarter initiative to start improving how your team handles tech debt. A few small, deliberate moves can immediately change the conversation.

Start by identifying the top three sources of recurring pain your team complains about. Not everything, just the things that keep coming up sprint after sprint. Categorize each one honestly: pragmatic, required, incidental, or symptomatic. The act of naming the type often clarifies the decision.

For any intentional debt, write down why you chose it, what problem it solved, and when you’ll revisit it. Put a reminder on the calendar. If you say you’ll come back in six months, actually do it.

For debt that feels urgent, force a business?impact discussion. What does this slow down? What risk does it introduce today, not someday? If you can’t connect it to outcomes, it probably isn’t required yet.

And if you see the same kinds of problems appearing across multiple areas of the system, pause before opening another refactoring ticket. Ask what incentives, structures, or capacity constraints are creating that pattern. That’s a leadership problem, not a coding task.

These steps won’t eliminate tech debt. They will make it legible. And once tech debt is legible, it becomes manageable.

Tech debt as a diagnostic

There’s a line I come back to often when thinking about this:

Tech debt is code telling you a people story.

The shape of your codebase reflects the incentives, constraints, and trade-offs your teams live with every day. Some debt exists because you chose speed over elegance. Some exists because the business changed direction. Some exists because no one ever had the space to step back and ask if the system still made sense.

Seen this way, tech debt becomes less about cleanliness and more about comprehension. It tells you where judgment was exercised well, where context shifted, and where leadership attention is overdue.

These days, I look at tech debt less as a technical flaw and more as a diagnostic signal. How much of it was intentional? How much is benign? How much is actively constraining outcomes? And how much is a warning that the organizational system, not the software system, needs work?

Start with intent. Then look at the system. Only then decide what to fix.

Reading the Signal

Tech debt isn’t inherently good or bad. It’s information.

If you treat every piece of debt as a defect, you’ll waste time and erode trust. If you treat every piece as harmless, you’ll create fragility that eventually surfaces at the worst possible moment. The leverage comes from understanding why the debt exists and what it reveals about your team and your organization.

Tech debt doesn’t derail teams. Unexamined tech debt does.

When you slow down enough to interpret the signal, rather than react to the symptom, you make better decisions for your team, your product, and your company.

Originally published in my newsletter at https://kevingoldsmith.substack.com/p/tech-debt-is-a-signal-not-a-sin

What Really Happens in a Board Meeting

Blaine, WA, USA – November 2025 – Photo by Kevin Goldsmith

Many companies treat their board meetings like something between a state secret and a seismic event. People talk about them in hushed tones. Execs disappear for days to “prepare the deck.” Afterwards, the chatter changes. Priorities shift. New projects materialize out of the ether.

If you’ve never been in a board meeting, it can all seem mysterious, and maybe a little ominous.

Board meetings aren’t actually mysterious. But they are consequential. Understanding what happens in that room can help engineering leaders feel more confident and prepared for the responsibilities ahead.

The Board Meeting Is the Company’s Performance Review

The easiest way to understand a board meeting is to think of it as a quarterly performance review, not for you, but for the entire company. The board’s job is governance, not day-to-day execution. But when you’re in the room, that distinction gets blurry.

Leadership walks in trying to demonstrate progress and competence. The board walks in looking for clarity, judgment, and evidence that the company is being run responsibly. That tension is always there, even when everyone gets along.

Most employees only see the aftereffects: sudden shifts in priorities, new urgency on old initiatives, or a directional change that seems to come out of nowhere. When you understand the meeting, those reactions make more sense. They’re the natural downstream effects of a conversation where the company’s leaders were held accountable for the plan they proposed.

The Board Isn’t a Shadow Government, But It Can Feel Like One

Inside most companies, the board feels invisible. You don’t meet them. You don’t email with them. Yet they’re the group that hires and fires the CEO. Even founders aren’t immune. When you hear “The CEO stepped down,” it usually means the board decided it was time.

That’s one reason board meetings carry so much weight. Executives know the stakes. And while boards rarely act on one bad meeting, repeated surprises or unclear thinking will put pressure on the CEO, which eventually rolls downhill.

I’ve even been in the room when an executive presented a plan so poorly, and after enough prior concerns, that the board effectively decided in the moment that they needed to go. That’s the exception, not the rule. But it illustrates the point: credibility is earned, and it can be lost.

Not All Boards Behave the Same

Boards vary widely depending on the company’s stage.

In early-stage or growth-stage startups, the board is often hands-on. Sometimes very hands-on. Because the board at this stage usually includes the company’s investors, individual members may push directly on product direction or dive deep into operational details. It isn’t always ideal, but early companies are fragile, and investors are understandably trying to protect their bet.

In founder-led companies, the dynamic shifts depending on who sits at the table. Early on, it’s often people the founder knows and trusts, which creates a more deferential tone. As more institutional investors arrive, that dynamic changes.

Later-stage boards tend to be more formal, more metrics-driven, and more focused on predictable execution. The meetings feel closer to performance evaluations, even when the culture is friendly.

One thing doesn’t change: a board reflects the CEO. Formal CEOs produce formal boards. Informal CEOs yield looser, more conversational meetings. The CEO sets the weather.

What Actually Happens in the Meeting

People are often surprised to learn how much preparation goes into a board meeting—weeks of it.

Everything centers on a shared deck: financials, KPIs, major initiatives, strategic updates, risk areas, hiring plans, and decisions requiring approval. That deck is reviewed, revised, rehearsed, and pre-briefed long before the board enters the room. By the time the meeting starts, the board already knows what they’re about to see, or should.

A typical meeting looks something like this:

The CEO sets the stage: what’s going well, what’s not, what leadership needs from the board.

Finance presents the numbers: revenue, runway, margin, CAC, churn; whatever matters most to the business model.

Product, marketing, and sales walk through their worlds: customer signals, wins and misses, market conditions, and upcoming bets.

If the company has made a significant strategic push: AI, international expansion, a new product line, there’s usually a deep dive.

Throughout all of this, the board probes. A good board isn’t antagonistic, but it’s direct. Their job is to test whether leadership is thinking clearly and operating responsibly.

At the end, there’s a closed session. No executives except the CEO (and sometimes CFO). That’s where the board talks candidly about leadership performance. It’s also why execs take these meetings seriously.

The CTO’s Seat at the Table

The funny part about board meetings is that the CTO is almost always there, but rarely the center of attention, even in technology companies. Most board members aren’t technologists. In my entire career, I’ve only had one board where someone truly came from a technical background.

That means the CTO’s job in a board meeting is translation.

As a CTO, your role is to translate complex technology into clear, business-relevant insights, focusing on risks, investments, and support needs, so that non-technical board members can make informed decisions.

When an initiative is technology-led (cost optimization, AI investment, infrastructure modernization), you’ll sometimes present directly. More often, your work shows up indirectly through product velocity, reliability metrics, margins, and sales enablement.

The worst thing a CTO can do is surprise the CEO in the room. A board meeting is not the moment for new revelations or unplanned detours. If you introduce something your CEO hasn’t already heard, and agreed belongs in the conversation, you’re forcing them to react in real time, in front of the people who evaluate their performance. Even if the content is harmless, the surprise signals a lack of coordination inside the leadership team, and boards pick up on that instantly.

The second worst mistake is over-indexing on detail. Most board members aren’t technologists, and they’re not there to adjudicate between queueing models or deployment patterns. If you dive too deep, you overwhelm them, lose the narrative, and inadvertently signal that you’re thinking tactically rather than strategically. Early in my career, I thought that being thorough meant being exhaustive. What it actually meant was that I didn’t yet understand what the room needed from me.

I’ve made both mistakes. You learn quickly because the feedback, explicit or implicit, is immediate. Part of growing as a technology leader is learning that clarity, judgment, and alignment matter far more in a board meeting than technical virtuosity. Your job isn’t to impress them; it’s to help them trust that the company’s technology function is in steady, intentional hands.

Who’s in the Room, and Why It’s Not Everyone

People often ask why the board doesn’t record meetings, why it doesn’t open them, or why they can’t sit in to “learn.” The simple answer is context. Board meetings include discussions of risk, strategy, personnel, and decisions that may never come to pass. Without proper context, those conversations can be misinterpreted, leading to unnecessary fear.

That’s why attendance is limited to the executive team and a handful of supporting leaders. It’s not secrecy for secrecy’s sake. It’s to keep the conversation honest and productive.

What the Board Really Pays Attention To

Across every board I’ve worked with, a few patterns hold:

  • They care most about outcomes, not implementation.
  • They want clarity and judgment, not technical depth.
  • They evaluate leadership as a team, not as individuals.
  • They notice inconsistency immediately: mixed narratives, mismatched data, executives talking past each other.

A board meeting isn’t the place to demonstrate how clever you are. It’s the place to illustrate how aligned and effective the leadership team is.

Managing the Human Side

Board meetings aren’t just business reviews; they’re relationship-driven human interactions. Boards bring their own histories, biases, experiences, and incentives. Investors think about returns. Independents think about governance and risk. Founders think about mission and control. Everyone around the table is pulling from their own mental models.

As an executive, you navigate that while staying steady. No defensiveness. No surprise opinions. No contradicting your peers in the room. If there’s a disagreement, work it out before or after the meeting, not in front of the board.

Board members pay closer attention to the executive team’s dynamic than most people realize. If they sense misalignment, they’ll push the CEO to fix it. I’ve seen that happen more than once.

After the Meeting

How leaders talk about the board to their teams matters. Saying “the board won’t let us” creates a shadow authority that disempowers the people actually making decisions. It also feeds the myth that the board runs the company.

They don’t. Leadership does. The board evaluates, approves, challenges, and guides. If they consistently don’t like what they see, they replace leadership. But they aren’t running the business day to day.

That distinction matters more than people think.

What to Take Away

Board meetings aren’t often dramatic. They’re not mysterious. But they are a critical part of how companies stay accountable and aligned.

For technology leaders, understanding them is helpful for two reasons.

First, it demystifies the decisions you see after every quarterly meeting. You understand why priorities shift and where specific pressures come from.

Second, it prepares you for the rooms you’ll eventually grow into. Because one day, you may find yourself sitting at that table. And once you’re there, the job is simple: be clear, be honest, be thoughtful, and never forget that the board is there to help the company succeed, not to trip you up.

That’s the work. And like most leadership work, it’s less about knowing the correct answer and more about showing good judgment when the stakes are high.

To hear an extended discussion of this topic, please listen to my podcast episode: https://itdependspod.com/episodes/demystifying-board-meetings-a-ctos-perspective/

This article was originally published at https://kevingoldsmith.substack.com/p/what-really-happens-in-a-board-meeting

Crafting a Technical Strategy That Actually Works

San Diego, USA – November 2025 – Photo by Kevin Goldsmith

It’s planning season for most companies. By the time November rolls around, the board decks are being assembled, the budgets are being scrutinized, and every technology leader, from the C-suite to frontline management, is being asked some version of the same question: Where are we headed next year?

Regardless of your scope, having a clear technical strategy is crucial. And not just a mental model you carry around in meetings; a documented strategy your team can reference, question, and ultimately internalize. The absence of that clarity is one of the fastest ways for an engineering organization to drift off course.

Why documenting a strategy matters

When there’s no shared strategy, every team ends up making decisions based on personal taste, excitement about a trend, or something they saw in a conference talk. Without a shared North Star, those decisions diverge quickly. I’ve seen it firsthand: people heading in different directions, not because they disagree, but because no one ever explained where the organization is trying to get to.

Misalignment shows up everywhere. Architectural choices start reflecting old org structures instead of future goals. Product partners become frustrated because engineering appears to be prioritizing strange work. The business begins to question why teams are focused on internal rewrites instead of delivering customer-facing value. From the outside, it can look like chaos.

The hard truth is that most of these problems aren’t technical; they’re leadership failures. They come from not taking the time to define, document, and communicate the strategy.

What a good strategy looks like

A technical strategy doesn’t need to be fancy, but it must align with the business. If the business wants to enter new markets, your strategy should account for internationalization, payments, compliance, and scale. If the company plans to grow revenue by 10×, your architecture needs to be able to handle a 10× load. If you’re betting on expanding into adjacent industries, you should know whether your current systems or your current talent can support that.

A useful strategy has a few characteristics:

It’s coherent. Not a bag of unrelated goals. All the pieces should pull in the same direction.

It’s understandable. Anyone in your org should be able to read it and explain it to someone else.

It’s written at the right altitude. Too detailed, and it becomes a roadmap. Too vague, and it becomes meaningless. The test is simple: can people use it to make better decisions without needing your permission?

It’s a living document. The world shifts—the business shifts. Your strategy should update when reality does, but not so often that no one can keep track of it.

And, this is important, you should ground it in both where you are and where you need to go. Strategy isn’t about predicting the future; it’s about preparing your team to meet it.

Start by working backwards

Amazon made “working backwards” famous, but the underlying idea is helpful in any organization: imagine the future state, then figure out what needs to be true to get there.

If everything were going well two years from now:

  • What would your architecture look like?
  • What pain points would be gone?
  • What capabilities would your team have?
  • What new markets or products would the business be ready for?
  • What skills would you need in the team that you don’t have today?

Once you can visualize that world, you can start mapping backwards to the key technical bets that move you in that direction. Those bets might look like:

1. Moving toward event-driven architecture

2. Eliminating or isolating legacy systems

3. Prioritizing observability

4. Making large structural changes like cloud migration

5. Reorganizing teams around more scalable patterns

6. Reskilling people as technology evolves

Each of those bets should be tied directly to a specific business outcome. Otherwise, it’s just engineering for engineering’s sake.

Don’t create strategy in a vacuum

If you’re in the C-suite, validate the strategy with your peers first. Make sure the rest of the executive team understands and agrees with it. They may have expectations you aren’t aware of, or strategic initiatives that need your support.

If you’re a VP, director, or EM, share your draft with your cross-functional partners. Product and design should understand how the strategy shapes what you will and won’t do. Their strategy should align with yours, and yours should align with theirs.

When strategies diverge, teams drift. When they align, the work feels almost frictionless.

Communicate relentlessly

Communication is where most leaders fail, myself included at times. Sharing the strategy once is meaningless. Most people won’t internalize it until they’ve heard it repeatedly, in different contexts, tied to real decisions.

Put it in your all-hands. Reference it during project kickoffs. Use it when explaining tradeoffs. Make it part of onboarding. Ask teams to explain how their proposals align with it.

The goal is to make the strategy the frame everyone uses to make decisions. When that happens, you suddenly spend far less time correcting teams and far more time accelerating them.

How you know the strategy is working

You shouldn’t need to police architectural choices. Teams will make decisions that generally align with your intent.

You should see less rework, fewer surprise escalations, and fewer “Why are we building this?” debates.

Product partners should understand why certain internal work matters.

Cross-team integrations should become easier because everyone is working towards the same future, not the one in their own heads.

Your platform should scale as the company scales, ideally without drama.

And, most importantly, people should feel like they understand the purpose behind their work. Purpose and autonomy are two-thirds of what drives intrinsic motivation. A good strategy gives people both.

Final thought

A technical strategy isn’t a crystal ball. It’s not about outsmarting the future. It’s about giving your team the clarity and context to face that future together, and build well along the way.

If you’ve been putting off writing your strategy document, now is a good time to make progress. Your team will thank you later, and honestly, your future self will too.

Originally published in my newsletter on November 16, 2025

Making Technology Choices That Last

Every few years, a new wave of technology arrives, and people in our industry start to declare that everything is about to change. Right now, that wave is generative AI. A few years ago, it was Web3. Before that, mobile and public cloud. Before those, the web itself. Some of these shifts turned out to be genuinely transformative. Others didn’t.

Having lived through enough of these cycles, I have learned that the excitement and fear are always the same. The hard part is never knowing in the moment which changes will last. The other hard part is that, as technology leaders, we have to make decisions about them anyway. Should we adopt this new thing? Wait it out? Ignore it? Every one of those choices comes with a cost.

AI is the current case study, but the real question is broader. How do we make technology choices at all? How do we separate what is genuinely important from what is just noise?

Curiosity with Discipline

Being a technical leader involves staying curious. You have to pay attention to what is happening in the industry. That means reading, listening, and talking to peers. You cannot afford to ignore change because sometimes it is not a fad at all. Sometimes it is the thing that allows the next generation of companies to surpass your company.

Hopefully, you don’t see this curiosity as a burden. You chose a career in technology, after all!

But curiosity alone is not enough. There has to be discipline behind it. I have seen teams that refactor constantly, switching frameworks every few months or adopting tools that promise faster builds or cleaner syntax. They expend a great deal of energy and end up standing in the same place. It is easy to confuse motion with progress.

The goal is not to be early. The goal is to be ready when it matters.

Knowing When to Pay Attention

When something new appears, the first question is not “should we use it,” but “should we even pay attention to it?” Most technologies take a while to prove themselves. They start with hobbyists and early adopters. Then you begin to hear about them in conference talks and blog posts. If you start to see teams you respect using it, that is a signal to look more closely.

There are exceptions. Sometimes, a new tool or framework solves a problem that nothing else does. If it unlocks something meaningful for your business or team, consider taking the risk of early adoption. But most of the time, patience pays off. You want to see that a technology has a community around it, good documentation, and some stability. You want to know that if the creator moves on, the thing won’t go away.

I have seen open-source projects from large companies become popular overnight, only to discover that they were designed to address those companies’ unique constraints. They required more effort to maintain than smaller teams could afford. The code was free, but there was a hidden cost in maintenance. Before adopting the new tool, ensure you are familiar with its operation and can use it efficiently.

Use the Curiosity Around You

You don’t have to do all the exploration yourself. The best engineering teams already have people who watch the industry and bring new ideas. You can turn that energy into a system.

Give people permission to explore. Encourage them to read, share, and experiment safely. Create a channel or regular forum where developers can showcase their work, whether it is a side project or a prototype. It shows them that curiosity is valued, not something to hide until after work hours.

You can tell a lot about your team’s culture by how it reacts to experimentation. If people are afraid to try things, they stop learning. If you reward them for exploring ideas responsibly, you build a team that continues to grow even when the company is stable.

Let the eager ones go first, but set boundaries. They should know what kinds of experiments are helpful in the business. Guide their curiosity. The best developers don’t need permission to learn, but they do appreciate direction.

Evaluating What You Find

When something looks promising, that is when leadership really matters. You have to evaluate it in a way that balances technical interest with business sense.

Start with questions:

  • What problem does this solve for us right now?
  • Is it mature enough for the scale and reliability we need?
  • What are the maintenance implications?
  • Who else is using it successfully, and what can we learn from them?

Build a small proof of concept. Keep it outside production at first. Compare it with what you already have. Measure performance, stability, and effort. Run it in parallel with your current solution so you can see real data before committing (shadow testing).

This part takes patience. It is easy to fall in love with a clean new abstraction or a faster benchmark. But the actual cost of new technology is rarely visible at the start. The hardest lesson I have learned is that the adoption work is always more expensive than it looks. The second-hardest is that we almost always underestimate the maintenance cost.

If possible, discuss with peers at similar companies. Ask them what happened when they tried it. Did it actually deliver value? Did it hold up? You can save months of effort just by learning from other teams’ experiments.

Managing the People Side

Every new technology comes with human change as well. Some team members will be excited. Others will resist it. Both reactions are normal.

The eager developers will show up ready to rebuild everything in the new tool. The skeptics will say there’s no need to change what already works. Both have a point.

Your job is to balance them. Channel the energy of the early adopters toward solving real problems. Give them structure and goals. At the same time, acknowledge the fear of the skeptics. For many engineers, expertise is tied to identity. When you replace a system they know deeply, it can feel like erasing years of experience.

Pair the enthusiasts with the skeptics. Let them learn from each other. Measure the results and share them openly. When the experiment works, celebrate the outcome. When it doesn’t, celebrate the learning. What matters is not whether every experiment succeeds, but whether the organization learns at a faster rate.

You cannot let your early adopters run wild, but you also cannot let the cautious ones stop progress. Most of the time, the right path sits somewhere between.

How to Adopt Deliberately

When you decide to move forward with something new, make it an experiment, not a crusade. Define a hypothesis about what you expect to gain. You may be looking for better scalability, lower costs, or a faster development cycle. Write that down. Then define how you will measure it.

Expect the transition to follow a change curve. Things will feel worse before they get better. People will struggle with the new approach and question why you made the switch. That is normal. Keep communicating what you are seeing and why you are continuing. When the metrics begin to show improvement, make that visible.

If it doesn’t deliver the results you hoped for, be willing to stop. End the experiment, share what you learned, and move on. That kind of clarity builds trust.

When it does work, document it. Recognize the people who led the effort. Build on that experience the next time. Adoption is not just a technical process. It is a cultural one.

Building a System for Technology Choices

The most successful organizations I have worked in treat technology decisions as part of their system, not a one-time event. They create space for discovery, experimentation, and evaluation before anything reaches production. They involve the team in technical direction, not just management.

If you are a CTO, you own the technology strategy; however, the best strategies often emerge from shared ownership. The people doing the work often see opportunities or risks before you do. Involve them. Encourage them to propose ideas, test them safely, and share what they learn.

After every adoption or rejection, hold a retrospective. Talk about what worked, what didn’t, and what to do differently next time. That habit turns random trial and error into institutional learning.

You can build a culture that views new technology not as a threat or distraction, but as an integral part of how the team evolves. Curiosity and discernment can coexist.

Closing Thought

Technology waves will keep coming. Some will reshape how we work; most will not. The challenge of leadership is recognizing the difference.

Good technology choices rarely come from being first. They stem from being thoughtful, from understanding your context, and from fostering a culture that learns quickly and acts deliberately.

The best technology decisions are not about what is new. They are about what is right for you, right now.

Originally published on my newsletter on November 02, 2025