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.

This article discusses the problems that arise when managers on your team make conflicting decisions.
https://kevingoldsmith.substack.com/p/every-decision-creates-a-policy
“Turn the Ship Around!: A True Story of Building Leaders by Breaking the Rules” by L. David Marquet. A good book on moving from controlling to delegating in management: https://amzn.to/49XH2Ty
Delegation Poker from Jurgen Appelo. Similar to the tool I describe in my talk above, but with more options: https://medium.com/@jurgenappelo/unclear-team-responsibilities-use-delegation-levels-985537dbea38

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

The Hidden Architecture of Engineering

Practical Lessons in Organizational Design

Introduction

Most engineering leaders inherit organizations they didn’t design. By the time we step into a role, the structure is already there: a mix of teams, reporting lines, and legacy decisions. It’s easy to accept that structure as “just the way it is.”

But structure quietly shapes everything. It defines how information flows, how decisions get made, how accountability works, and how fast (or slow) a company can move. The org chart isn’t just a management artifact; it’s a piece of system design.

Over the years, I’ve learned that organizational design is one of the most potent tools a technology leader has, and one of the least understood. You can’t manage around a broken structure any more than you can code around a broken architecture.

Inheriting the System

I’ve only had a few chances to design an organization from scratch, usually in early-stage startups. More often, I’ve inherited something that had evolved over time. Some were the result of thoughtful planning. Others grew like weeds.

Every organization reflects its history. Even the most ad-hoc structure is an artifact of past decisions: who talked to whom, what problems needed solving, what crises shaped the company.

That’s Conway’s Law in action: organizations design systems that mirror their communication structures. Look closely at a product’s architecture and you’ll see its org chart.

In the product engineering organization I led at Adobe, my teams were arranged by function: one group focused on building the backend, while others managed clients, core libraries, and infrastructure. This was the standard team structure at the time, but it limited our speed. Each feature had to go through four different teams, each operating on its own sprint cycle. As a result, it could take months to ship a simple feature because it needed to pass through each layer of the teams.

When I joined Spotify, the structure was entirely different. Autonomous, cross-functional squads owned features end-to-end. They deployed independently and moved fast. The system’s modularity came directly from the team design.

Different problems, different structures. Both logical in their contexts, but the lesson is constant: you ship your org chart.

Designing for Purpose, Not Precedent

Too many companies treat organizational design like a template. Someone says, “Let’s use two-pizza teams like Amazon,” or “Let’s adopt the Spotify model.” The intent is fine, but the context is missing.

Amazon and Spotify built those systems because they fit their culture, strategy, and scale. Copying the form without understanding the function is like cloning another company’s codebase without knowing its dependencies.

The real question isn’t “what structure should we have?” It’s “what problem are we solving, and what design will align our teams to solve it?”

Structure is strategy made visible. A good design aligns incentives, communication patterns, and ownership boundaries with your goals. It creates high-bandwidth communication where you need it and separation where you don’t.

And it has to evolve. The organization that works for a 20-person startup will break at 100. The one that works at 500 will creak at 2,000. Like software architecture, organizational design is never finished.

Diagnosing What’s Broken

You don’t redesign an organization because it’s old. You redesign it because something isn’t working.

My favorite diagnostic tool is simple: follow the work.

Take one feature or story and trace it from idea to production. How many teams does it touch? How many handoffs? How long does it sit idle?

Every delay is a clue. Sometimes it’s a resourcing issue. Sometimes it’s a missing skill in a team. But often, it reveals deeper misalignments: unclear ownership, too many dependencies, too little trust.

At Adobe, that exercise made the bottlenecks obvious. Each feature touched four teams in sequence, and a “simple” change could take three months due to the handoffs. At Spotify, where squads owned the full stack, the team shipped the same kind of work in a single sprint. It wasn’t magic. It was designed.

If you want to understand why your organization feels slow, follow the work.

Lessons from Team Topologies

If Conway’s Law explains why structure and systems mirror each other, Team Topologies by Matthew Skelton and Manuel Pais gives you language for designing around that reality.

They identify four core team types:

Stream-aligned teams own a product or flow of work end-to-end.
Enabling teams help others improve tools or skills.
Complicated subsystem teams handle specialized areas of expertise.
Platform teams create shared systems that reduce cognitive load.

They also describe three ways teams interact: collaborate closely for a time, provide something as a service, or facilitate learning.

The value isn’t in the framework itself; it’s in the vocabulary. It helps leaders think about flow instead of hierarchy and design structures that reduce friction instead of adding layers.

When I read Team Topologies, I recognized much of what we’d already been doing at Spotify; the authors had spent some time at the company. But I also saw patterns from earlier roles that suddenly made sense in hindsight. The book doesn’t prescribe. It clarifies.

Common Patterns and Traps

Most organizations follow predictable patterns as they grow.

Functional silos work early but become brittle later. They make coordination explicit but slow.

Cross-functional teams increase autonomy and speed but come with a higher cost. At Spotify, that meant hiring more mobile developers than most companies would ever consider. It worked because the company optimized for velocity over constraining headcount.

Centralized data or infrastructure teams start strong, then evolve into bottlenecks. You have to anticipate when to distribute those capabilities.

Matrix organizations can preserve continuity and reduce disruption when people change teams, but they also add complexity quickly. They work best when accountability is crystal clear.

And then there’s the most common anti-pattern: designing around personalities. Building an org around one person’s strengths, or avoiding their weaknesses, might seem practical in the short term. It always becomes debt later.

Reorgs as Refactors

When a structure stops working, treat the reorg like a refactor, not a revolution.

Don’t blow everything up. Make small, deliberate changes. Be transparent about what you’re solving and how you’ll measure success. Make the problems you are trying to solve clear, and how you will handle the case where the structure change doesn’t solve them.

The biggest mistake leaders make is reorganizing at people instead of with them. Change feels arbitrary when the reasoning is hidden. If people understand the problem, they’ll accept the solution even if they don’t love it.

Every reorg has a sociotechnical cost. You’re not just moving boxes. You’re changing relationships, communication paths, and identity. Handle it with clarity and care.

Reorgs should feel like system refactors, not revolutions.

Leading by Design

Organizational design isn’t a one-time project. It’s an ongoing act of leadership.

Start by mapping your current system: who talks to whom, where decisions stall, and where ownership is ambiguous. Align the structure with your strategy and your culture.

Design for clear interfaces between teams and between roles. Iterate carefully, explain your reasoning, and gather feedback.

The structure that got you here probably won’t get you where you need to go—and that’s okay. Good organizations, like good architectures, evolve.

If you drew your company not as boxes and lines in a directed acyclic graph, but as flows of information and work, what would it look like? Where would the friction be? Where would it hum?

That picture, not the official org chart, but a system diagram, is the authentic architecture you’re building every day.

To hear an extended discussion of this topic, please listen to my podcast episode: https://itdependspod.com/episodes/the-hidden-architecture-of-engineering-practical-lessons-in-organizational-design/

For more about Conway’s Law and my experiences utilizing it in organization design, see the video of my talk Architecture and Organization.