Category: Professional Development

Every Organization Is a System. Are You Designing It or Just Living in It?

Most leaders develop systems thinking by accident. Here’s how to build it on purpose.

Seattle, USA – Photo by Kevin Goldsmith – March, 2026

I emphasize learning systems thinking, but I haven’t explained how to build the skill. I often highlight its importance, yet I rarely give people actionable steps to develop it.

My systems thinking is intuitive now, and most senior leaders I know developed it the same way: informally, through experience. This makes it seem innate rather than a skill to practice.

In this piece, I’ll lay out what systems thinking looks like, how to start developing it, and how to improve it over time. I’ll preview a specific framework and a set of practical exercises designed to help you put systems thinking into practice. If you’re looking for concrete guidance you can use right away, you’ll find it, read on.

The Two Modes

There’s a tension at the core of leadership that most people feel but don’t name: leaders must balance transactional management—defining rules, assigning tasks, creating incentives, and fixing problems as they surface —with systems thinking—understanding and addressing the underlying structures that produce those problems and results.

Transactional management works fine for small teams and short time horizons. It works for early-stage startups that are just trying to survive. But it hits a ceiling. As scope grows, the problems multiply faster than any individual leader can address them. Leaders who stay transactional end up playing whack-a-mole with symptoms instead of addressing root causes. If every problem you solve creates two new ones, you’re not solving problems. You’re rearranging them.

If you’ve been part of a small startup that grows into a larger company, you’ve felt this. In the early stage, transactional thinking works because you’re just trying to make it to next week. But as the company grows and time horizons lengthen, that operating mode starts to hold you back. That’s when you need to shift into thinking about the system you’re in and how to improve it.

Systems thinking is the shift from ‘why is this person not delivering?’ to ‘what’s making it hard for this person to deliver?’ Though subtle, this shift changes where you focus your attention. It also connects directly to strategy. When you understand the system, you can anticipate how a change in one place will affect another. That foresight, seeing second-order effects, links strategic and systems thinking as leaders advance.

The gardener metaphor is one I keep coming back to. You can plan a garden down to the centimeter: this rose here, that plant two inches away, exactly this many leaves. It can all be laid out on paper. Still, when you plant the seeds, and they grow, you’re going to get what you get. The goal isn’t to match the plan exactly, but to create conditions where good things grow. You guide and shape, yet the end result will always emerge from the living things involved. Often, the outcome is even better than planned because of the people who are part of it. That’s systems thinking in practice: you’re aiming for a positive outcome, not an exact one.

A Four-Stage Progression

I’ve put together a framework for developing systems-thinking skills. It moves through four stages, from observation to intervention. Think of it as a progression, with each stage building on the one before.

Stage One: See the System

Most people see individual actions, decisions, and outcomes. The first step is recognizing that these are connected by structures, incentives, and dependencies that aren’t always visible. There is a system beneath the visible activity of your organization, and until you start looking for it, you won’t see it.

I hear this all the time, even from people on my own teams: “This team is really slow. What’s wrong with them? Why aren’t they working harder?” But nobody has actually talked to that team. Nobody has asked what they’re dealing with. Maybe they have a poor set of tools. Maybe they’re waiting on another team for something that isn’t visible from the outside. It looks like a people problem, but if you ask the next “why,” you often discover it’s a structural one.

That shift in thinking is foundational. Instead of blaming the team or developer, ask: What conditions make it difficult for them to get their work done?

Stage Two: Map the System

Once you’ve started seeing the system, the next step is to make it visible to yourself and others. Draw the relationships between teams, trace workflow, and identify decision points and bottlenecks. Making the system explicit sets the stage for productive conversations.

When I join a new company, the first thing I do is talk to everyone, not just people in my organization but all the organizations around it. I ask what’s working and what isn’t from both inside and outside perspectives. That gives me more than a list of problems. It starts to reveal the interconnections between teams. Two companies can adopt the same team model and end up with completely different dependency maps. You can’t see that from an org chart. You can only learn it by talking to people.

People will tell you things like ‘we’re constantly waiting on this other team’ or ‘that group keeps dropping work on us.’ These aren’t just complaints, they’re signals about how the system operates. As you collect these, create a map: put teams on a board, draw connections and dependencies, using any tool that works for you. This process clarifies unseen structures.

This map is not a secret document. I share it with people and ask them to correct it. And this is important: the conversations the map generates are often more valuable than the map itself. People will look at it and tell you, “This is wrong, that’s not how it actually works.” That correction process surfaces things you wouldn’t have found on your own. Update the map as you learn. The org chart tells you who reports to whom. A systems map tells you how work actually gets done.

I also look at specific teams and count how many dependencies other teams have on them, and how many dependencies they have on others. Sometimes it looks like the product team is the bottleneck, but when you map it out, the real constraint is elsewhere entirely. It isn’t obvious from the outside or even from the inside until you visualize it. Having that map gives you a way to talk about problems concretely, not as hunches but as visible structures.

Stage Three: Understand How the System Constrains and Enables

Once you have the map, analyze where the system is helping and where it’s hurting. Where are the bottlenecks? Where are the feedback loops? Where are the incentives driving behavior, and are they producing the behavior you actually want?

Donella Meadows’ Thinking in Systems is excellent on this. She describes how systems have sources, sinks, and bottlenecks. In a product development organization, your sources of features and bugs are the sales, marketing, and product teams, as well as developers themselves. Your sink is usually shipping code to 100% of your customers. The path between those two points, and the things that slow it down or speed it up along the way, is the system you need to understand.

This analytical layer helps you recognize patterns across different situations. Misaligned incentives are a common problem: for teams not meeting expectations, examine what they are incentivized to do. Consider how performance is measured and rewarded, as these nearly invisible structures often explain dysfunction. You only see them when you look deliberately.

If you don’t like the behavior a system is producing, look at the incentives before you look at the people. A lot of friction between teams comes down to teams being incentivized for different outcomes instead of the same one.

Stage Four: Intervene with Awareness of Cascading Effects

This is the hardest stage, as it means predicting second-order effects and managing disruption from improvement. When you fix one part of the system, you might unexpectedly impact another. Anticipating this is critical to solving more problems than you create.

To help with this, I suggest using a simple tool before making any system intervention: run through a checklist or set of questions that prompt you to consider potential ripple effects. Here are a few to start with:

  • What are the upstream and downstream teams or processes touched by this change?
  • What current bottlenecks does this affect, and where might new bottlenecks appear?
  • Who stands to lose or gain power, resources, or visibility as a result?
  • What informal processes or workarounds are people relying on that could be disrupted?
  • What data or feedback loops exist to help you catch unexpected impacts quickly?

Asking these questions up front does not guarantee you’ll predict every effect, but it improves your odds and makes you a more responsible systems thinker.

Here’s a current example I’m thinking about a lot. Engineering teams adopting AI tools are getting faster at code generation. That sounds like pure upside. But the entire system around software development was built for a world where engineering was the bottleneck. Software development has been time-consuming and expensive for decades, and the industry’s practices are all organized around maximizing engineering capacity because it’s the scarcest resource.

Now, engineering is becoming less of a bottleneck. That should mean everything goes faster. But consider what happens. Product teams are used to having time to research and prepare features for engineering to pick up, because engineering consumes that work slowly. When engineering suddenly moves faster, the product team can’t feed the backlog fast enough. You’ve put back pressure on the product team. On the other hand, if you have a QA team staffed relative to engineering’s slower output rate, they’re now getting backed up as well. You’ve solved one bottleneck and created two new ones.

That’s not a reason to avoid the change. But if you don’t see the system, you won’t anticipate those downstream effects until they’re already causing problems. And if you solve the product bottleneck, then something upstream of the product team becomes the constraint. If you solve the QA bottleneck, you might now be putting pressure on the infrastructure, marketing, or sales teams. Understanding these cascading effects is what separates someone who can see a system from someone who can actually intervene in one effectively.

More broadly, AI and agentic systems are, at their core, systems design problems. When you design an AI workflow, you’re building a system with components that interact, handoffs between steps, feedback loops, and failure modes. Leaders who think in systems will design better AI implementations because they already understand how components interact and where things break down. Without systems thinking, leaders will treat AI adoption as a tool problem rather than a system problem. And adding AI to a broken process just gives you a faster broken process.

When You’ll Meet Resistance

Some people see systems thinking as cold or mechanical, as an attempt to turn people into interchangeable parts in a machine. When you try to map out what are essentially human relationships and team dynamics, very organic and people-centered things, some people will resist that framing.

It’s worth addressing directly. Systems thinking is not about treating people as cogs. It’s about making the environment around them better so they can do their best work. That gardener metaphor matters here: you’re not engineering a machine. You’re creating conditions for living things to grow.

You’ll also face friction from peers who operate in a more transactional mode. Sales teams tend to be exceptionally transaction-driven by nature. A lot of the tension I’ve experienced, and that the people I mentor experience, comes from engineering leaders trying to be long-term and systems-oriented, while transactional leaders in other parts of the company need everyone to work the way they do. The “doing stuff” approach, more reorgs, more reassignment, more process, looks productive in the short term. When you’re building systems, it can look like you’re not doing much because the changes are structural rather than visible activities.

This is where communication becomes critical. I learned this the hard way. At one company where I was CTO, I was building better systems, and the improvements were real, but I wasn’t explaining what I was doing well enough. My executive peers, particularly on the sales side, were getting impatient. I could have forced changes through transactionally, but that wouldn’t have produced what they actually needed next. The problem was that from their perspective, they couldn’t see the system I was building. The results weren’t proving fast enough, and I wasn’t making the progress visible. The system I forgot to work on was the one between my peers and me.

That failure taught me something important. Building a better system is not enough if the people around you don’t understand that you’re building one. Systems-level change takes time, and organizations are full of people who want faster answers. When you can hold the line long enough for the system to start producing results, people will become supporters. But if your peers and your leadership don’t understand your work on system-level improvements, they’ll evaluate you on surface-level metrics and lean into quick fixes that undermine what you’re building. Your job is to narrate what you’re doing and why, especially to people who think differently about management. Make the work visible. Show early wins. And keep communicating the trajectory, not just the current state. Communication about system-level work needs to be ongoing, not a one-time explanation.

That said, context matters. Long-horizon systems work is much easier in companies that are doing well. If your company is struggling and just trying to survive, that’s not the time for building systems that take years to produce results. Sometimes transactional leadership is the right match for the situation. Early-stage startups are transactional, and that works because they’re focused on survival. The goal isn’t to always be a systems thinker. It’s to know which mode the situation calls for.

In reality, most organizations need to blend both modes. Urgent issues often require transactional action, even as you continue system-level changes to achieve sustainable improvements. For example, you might handle a critical customer escalation with a quick fix while simultaneously documenting what led to the problem, and then working on a system change to prevent it from happening again. The best leaders combine systems thinking to shape the environment over time with the ability to execute decisively in the moment. That means communicating when you switch between modes, so your team understands why you act one way now and another later. Hybrid approaches let you address today’s fires while still laying the foundations for tomorrow.

Building the Skill in Practice

The progression gives you a mental model. But you also need concrete exercises to develop the skill. Here are the ones I use and recommend.

Map the dependencies when you join a new organization or take on a new scope. This is the first thing I do, and I think it’s the most valuable. Draw how teams relate to each other, not the org chart but the actual working relationships: who depends on whom, where handoffs happen, where shared resources create contention. You can only learn this from talking to people and asking them what’s working and what isn’t. They’ll tell you, especially if you’re new, because it’s not from a decision you made, and they’re hoping you’ll improve things.

Follow a piece of work end-to-end. Pick a feature, a bug fix, a customer request, and trace it from origin to delivery. Document every handoff, every queue, every approval step, every place it sits waiting. Look for the accumulation of small delays, not just the obvious bottlenecks. And remember that this map extends past your organization. You can fix your part of something, but your team is not the full system.

At one company, we had a velocity problem we couldn’t explain. The teams were good. The processes seemed fine. There wasn’t an obvious bottleneck. I asked one of my leaders to try this exercise: take a single piece of work and follow it through the entire organization. What we found wasn’t one big slowdown. It was dozens of small friction points, a day waiting here, two days waiting there. Each one was individually insignificant, and people were aware of them locally. But nobody had seen the accumulation. When you added them all up, they explained the entire velocity gap.

We streamlined those friction points and improved velocity without asking anyone to work harder. Everyone was already working hard. The system was working against them. It was only when we mapped how work moved through the system that this became visible. You can start this kind of exercise in Jira, but you can’t do it all automatically. You have to attend the standups, attend the retros, and follow the actual path. I’ve tried to do it purely through tooling multiple times. It doesn’t work.

Trace how a decision got made. Pick a recent decision and work backward. Who made the final call? What information did they have? Who influenced it? How long did it take, and where did it stall? This surfaces hidden power structures, information bottlenecks, and approval layers that slow the organization down. It also reveals whether the people closest to the problems are making the decisions or whether decisions are unnecessarily being escalated. This exercise is easier if you’re a senior leader who can see the full chain, but it’s worth attempting at any level.

Map incentive structures. For a team or group of teams that aren’t producing the outcomes you expect, look at what they’re actually incentivized to do. Examine how performance is measured, what gets rewarded, what gets punished, and what gets ignored. When I see bad behavior or misaligned priorities, I usually see perverse incentives at work. Teams incentivized for different outcomes rather than the same one will create friction among themselves, and that’s a system problem, not a people problem.

Start This Week

Systems thinking is not an advanced leadership concept reserved for CTOs. It’s a skill that can be developed at any level, starting with the simple act of looking beyond individual performance to ask how the structure around people shapes their work.

Pick one exercise and try it this week. If you are looking for the quickest way to open your eyes to systems thinking, start by mapping the dependencies between the teams you work with. I recommend this as the most impactful starting point, especially for first-timers or anyone short on time. It’s a simple, concrete way to see how your work fits into the bigger picture, and it often surfaces underlying issues you hadn’t noticed before. If you want a deeper dive, follow one piece of work from start to finish and write down every place it pauses. You can also trace how a recent decision actually got made, or look at an underperforming team and ask what they’re incentivized to do versus what you want them to do.

I also recommend two books that shaped my own thinking. Donella Meadows’ Thinking in Systems is the best foundational text I know on the subject. And Jurgen Appelo’s Management 3.0 integrates systems thinking throughout without always calling it by name.

Every organization is a system. The question is whether you’re designing it or just living in it.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Every Organization Is a System. Are You Designing It or Just Living in It?

Originally published in my newsletter

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

Making the Most of an Unplanned Career Break

Strategies to Stay Competitive and Interview-Ready During Extended Job Searches

Making the Most of an Unplanned Career Break

The tech industry continues to face challenging times, with layoffs affecting professionals at all levels of the industry. If you’re currently between roles, whether it’s been three months, six months, or longer, you’re not alone. Unfortunately, there’s still a perception that extended unemployment reflects poorly on the individual rather than industry conditions. Here’s how to turn an unplanned career break into a strategic advantage while preparing compelling stories for your next interview.

Reframe Your Career Break

I often see people list “career break” to cover a gap between roles. While people do this as a deliberate choice to recharge, you can also use this on your resume to reframe an extended job search. Simply listing “career break” on your resume isn’t enough. Be specific about what you’re doing with that time. Are you learning new technologies? Earning certifications? Developing new skills? This shows you’re staying engaged with industry developments and taking your professional growth seriously, even while job searching.

More importantly, each skill you develop gives you fresh material for interviews. When interviewers ask about recent learning or how you stay current with technology trends, you’ll have concrete examples: “During my career break, I dove deep into Kubernetes and earned my CKA certification. I also built a personal project using React 18’s new concurrent features to understand how they improve user experience.”

If you’re using “career break” to account for job search time, limit this approach to six months maximum unless you’re genuinely taking an extended, planned break. You can use the end of your “career break” time on your resume as an opportunity to restart your job hunt, looking fresh to recruiters.

Start a Consulting Company

Creating a consultancy demonstrates you’re still actively working and using your skills, even if you’re not employed full-time. Yes, building a consultancy is challenging, especially without strong existing connections, but it shows initiative and keeps you in the professional game.

In interviews, consulting experience provides rich storytelling opportunities. You can discuss how you navigated different client needs, adapted to various tech stacks, or solved problems with limited resources. “Working with three different clients taught me to assess legacy systems and propose pragmatic modernization strategies quickly” is far more compelling than explaining a gap in employment.

Be strategic about the contracts you accept, ensuring you can transition away if a full-time opportunity arises. Use any downtime between clients to develop new skills or pursue certifications that enhance your value proposition and give you additional interview talking points.

Build a Startup

Don’t let the complexity intimidate you; starting a startup can be as simple as developing an idea and creating a website. This approach works particularly well for senior leaders who want to demonstrate they’re still innovating and building.

The interview advantages here are enormous. When someone asks, “Tell me about your startup,” you have a natural opportunity to showcase technical decisions, product thinking, and problem-solving approaches. You can explain why you chose certain technologies, how you validated assumptions, what you learned about user experience, or how you approached scaling challenges. These conversations demonstrate both technical depth and business acumen.

Most startups fail, and hiring managers understand this. What they’ll appreciate is your initiative, the skills you’ve developed, and the concrete experiences you can discuss. Be prepared to explain your transition: “After eight months, I realized the market timing wasn’t right, but I learned invaluable lessons about modern deployment strategies and user research that I’m excited to bring to a larger team.”

Address the obvious question directly: “I’m ready to shelve the startup and focus entirely on this role. The experience taught me what I love about building products within a larger organization rather than going it alone.”

Contribute to Open Source Projects

Open source contribution keeps you coding, collaborating with teams, and engaging with the broader tech community. As a significant user of open source software, contributing back is both professionally beneficial and ethically sound.

This path creates specific technical stories for interviews. You can discuss code review processes, how you approached complex bug fixes, or how you collaborated with maintainers across time zones. “I contributed a performance optimization to [popular library] that reduced memory usage by 30%” is a concrete achievement that demonstrates both technical skill and impact.

While “open source contributor” might not carry the same weight as other options on your resume, it’s meaningful work that demonstrates ongoing skill development. Plus, becoming a key contributor to a popular project can lead to networking opportunities and potential job connections.

Volunteer Your Technical Skills

Consider leveraging your expertise for charitable organizations that need technical support. Many nonprofits struggle with outdated systems, a lack of digital infrastructure, or limited technical resources. Volunteering your skills provides several benefits:

  • Real-world impact: You’re solving genuine problems for organizations, making a difference
  • Portfolio building: These projects often involve diverse technical challenges and constraints
  • Interview gold: “I built a volunteer management system for a local food bank that increased their efficiency by 40%” shows both technical capability and values alignment
  • Leadership stories: Smaller organizations often give you more responsibility, providing examples of how you drive technical decisions and manage stakeholder relationships
  • Problem-solving under constraints: Nonprofit projects typically involve limited budgets and resources, showcasing your ability to deliver value with creative solutions

When discussing volunteer work in interviews, focus on the technical challenges and business impact rather than just the charitable aspect. “Working with a limited hosting budget taught me to optimize for performance in ways I hadn’t considered in enterprise environments.”

Strategic Interview Messaging

Whatever approach you choose, be prepared to explain your transition back to full-time employment confidently. Frame your experience as intentional professional development: “I used this time to explore entrepreneurship and deepen my technical skills. Now I’m excited to bring these fresh perspectives and enhanced capabilities to a collaborative team environment.”

Each path gives you concrete examples of continued growth, problem-solving ability, and professional commitment. The key is having specific stories ready that demonstrate how your career break time made you a stronger candidate, not someone who’s been out of the game.

Remember, showing that you’ve remained productive and engaged during your career break demonstrates resilience, self-motivation, and commitment to your profession; qualities any employer would value. More importantly, you’ll walk into interviews with fresh experiences and genuine enthusiasm for what you’ve learned and built.

Originally published at https://kevingoldsmith.substack.com/p/making-the-most-of-an-unplanned-career

The CTO’s Guide to Crafting a Technology Leadership Resume

Crafting a resume as a technology leader is about more than listing roles—it’s about showcasing achievements, leadership, and strategic impact. Learn how to tailor your resume, highlight cross-disciplinary management, and leverage tools like LinkedIn and personal websites to stand out for executive roles.

A common discussion with people I mentor is how to properly structure a resume or Curriculum Vitae. It comes up often enough that I felt compelled to write about it last year: “Sweat the details on your resume, especially if you are a developer or technology leader.” In the last few weeks, I have reviewed multiple resumes from folks hoping to achieve a director-level or above role. I wanted to share some lessons on how an executive-level resume differs from others in Technology.

As a technology executive, your resume is your calling card—a teaser trailer for your professional achievements. Crafting a resume that highlights your leadership journey while demonstrating value is an art form, particularly as you aim for senior roles like VP, CTO, or similar. Here are key takeaways and strategies to ensure your resume stands out.

Tailor Your Resume for the Role

Your resume isn’t a one-size-fits-all document. Different audiences—recruiters, hiring managers, or automated systems—expect varying levels of detail. To make a strong impression:

  • Create multiple versions of your resume:
    • Short-form (2 pages or less): Use this for recruiters or direct submissions. Focus on succinct highlights that convey your biggest achievements and relevant experience.
    • Comprehensive (full-length): Maintain this detailed record for Applicant Tracking Systems (ATS) or contexts where exhaustive experience matters, such as certain consulting or academic roles.
  • Use strategic brevity: Each version should prioritize accomplishments and impact over exhaustive lists of tasks or skills. At the bottom of the short-form resume, include a URL to your full-length resume, LinkedIn profile, or personal website for those who want more detail.
  • Tailor content to the role: If applying to a startup, focus on entrepreneurial accomplishments. For a multinational corporation, emphasize experience working with large teams or global operations.

Focus on Achievements, Not Responsibilities

Leadership resumes should emphasize measurable outcomes rather than generic responsibilities. This allows you to demonstrate value and differentiate yourself from other candidates. Consider these approaches:

  • Use metrics whenever possible: Quantify your achievements to provide concrete proof of your impact. For example:
    • Replace “Managed a team of data scientists” with “Grew a data science team from 5 to 20 members, delivering a 10x cost efficiency improvement in critical business processes.”
    • Instead of “Improved system performance,” say, “Increased platform uptime from 97% to 99.9% while reducing hosting costs by $500,000 annually.”
  • Highlight transformative initiatives: If you drove major changes—like adopting a new technology stack or transitioning a team to a new operating model—emphasize these innovations and their outcomes.
  • Demonstrate multi-disciplinary management: Showcase examples where you’ve managed diverse teams or disciplines, such as engineering, product, and design. For example, “Led cross-functional teams spanning software development, UX design, and data analytics to deliver a platform used by over 10 million users.”

Put Your Most Recent Role First

Your current or most recent position carries the most weight. It’s likely the first thing a recruiter or hiring manager will read, so ensure it captures attention:

  • Make it prominent: Place this role on the first page and dedicate the most space to it.
  • Emphasize scope and results: Clearly articulate the scale of your responsibilities, such as budget size, team size, and direct impact on the company.
  • Focus on strategic leadership: Highlight initiatives you spearheaded and the outcomes they achieved, particularly those demonstrating thought leadership, cross-functional collaboration, or innovation.

Save earlier roles for subsequent pages, reducing detail as you go further back in time. Roles older than 10 years may only need a line or two unless they’re particularly relevant.

Position Skills Strategically

Technical skills are critical, but how you present them matters:

  • Avoid generic lists: Instead of placing a large block of skills at the top, embed them within descriptions of your achievements. For example:
    • “Led migration to AWS Cloud, saving $1.2M annually and achieving 99.9% uptime.”
  • Highlight relevant expertise: Tailor the skills you emphasize to the role you’re applying for. If you’re aiming for a director role in AI, showcase experiences involving ML frameworks and tools like TensorFlow or PyTorch.
  • Subtly include soft skills: While technical skills are important, leadership roles often require strong interpersonal and strategic abilities. Show how you led teams, resolved conflicts, or drove cross-departmental alignment.

Summarize Career Progression

Rapid promotions and career growth can be a powerful selling point, but they need to be presented succinctly:

  • Highlight trajectory: For example, “Promoted from Senior Machine Learning Engineer to Head of AI within three years.”
  • Simplify titles: If your roles had incremental changes, summarize them into a cohesive narrative. For example: “Advanced from Senior Engineer to Director of Engineering over six years, culminating in leading a 50-person team and delivering $20M in annual revenue growth.”
  • Emphasize leadership: Show how your roles evolved to include greater responsibility, larger teams, or more strategic initiatives.

Cut the Fluff

Hiring managers and recruiters skim resumes. Get to the point by removing irrelevant or overly detailed information. This will make your resume more focused and efficient, ensuring that only the most important details are highlighted.

  • Avoid generic claims: Statements like “Proven leader” or “Results-oriented professional” don’t add value. Instead, provide examples that demonstrate these qualities.
  • Skip common experiences: Transitioning to remote work during COVID-19 isn’t unique. Focus on outcomes that set you apart.
  • Reduce early-career details: Unless highly relevant, roles from over 10 years ago should only include titles and dates.

Use LinkedIn and a Personal Website for Depth

Your LinkedIn profile and personal website can complement your resumé by providing additional details and ensuring you’re findable by recruiters:

  • LinkedIn:
    • Include all positions and significant accomplishments.
    • Add media or links to showcase notable projects, talks, or publications.
    • Use keywords strategically to improve searchability for specific roles.
  • Personal website:
    • A personal website can be a dynamic portfolio, host your detailed resume, and provide links to your projects, publications, or conference talks.
    • Organize your website by sections, such as Leadership Roles, Key Achievements, and Speaking Engagements, to make it easy for recruiters to navigate.
    • Use your website to expand on areas that wouldn’t fit in a resume or LinkedIn profile, like detailed case studies or thought leadership pieces.

Think Like a Hiring Manager

Your resume should:

  • Reflect strategic thinking: Tailor information to the audience and highlight your ability to align your work with organizational goals. This approach will make your resume more strategic and thoughtful, resonating with the hiring manager’s perspective.
  • Demonstrate leadership: Showcase your leadership skills by using examples of team management, cross-functional collaboration, or strategic initiatives. This will make your resume more confident and assertive and reflect your leadership potential.
  • Inspire curiosity: Provide just enough detail to make recruiters and hiring managers want to know more about you.

Remember, the goal of your resume is to secure a conversation—not to answer every question upfront.

Advice for Aspiring Executives: Breaking Into Leadership Roles

If you’re seeking your first executive-level (Director or above) role, your resume needs to convey readiness and potential:

  • Reframe your achievements: Highlight instances where you took on responsibilities beyond your official role, such as:
    • Leading cross-functional initiatives.
    • Mentoring junior staff or peers.
    • Driving strategy or innovation.
  • Show leadership impact: Even if your title doesn’t reflect it, focus on achievements that demonstrate leadership qualities, such as:
    • “Initiated and led a company-wide migration to DevOps practices, reducing deployment time by 80%.”
    • “Mentored three engineers who were later promoted to senior positions.”
  • Emphasize thought leadership: Include speaking engagements, publications, or significant contributions to open-source projects to showcase your influence in the field.
  • Network strategically: Your resume is only part of the equation. Attend industry events, contribute to discussions on platforms like LinkedIn, and seek mentorship from executives who can provide guidance and referrals.
  • Communicate readiness in your summary: Begin your resume with a compelling summary that positions you as an emerging leader. For example:
    • “Engineering Manager with a proven track record of driving strategic initiatives and leading high-performing teams, seeking a Director role to deliver innovative solutions at scale.”

Breaking into executive roles requires showcasing your potential and articulating how your experience aligns with leadership expectations. By tailoring your resume and approach, you can make the leap into senior management.

By taking a strategic, minimalist approach to your resume, you’ll showcase your accomplishments and demonstrate your ability to communicate effectively—a critical skill for any technology leader.

You should give that talk or write that blog

Me speaking at a conference

At least once a month, someone in a 1:1 or a mentoring session will ask me why I write these articles or give talks at conferences and want to know how they could get started themselves.

It can be daunting if you’ve never published something with your name attached or spoken in front of a group of your peers. The most common fear I hear is that people are afraid that they “have nothing to say” or relatively nothing to say that is new.

I give everyone the same advice.

You are the only person in the world that has your experiences. If you tell your story, no one will have heard it before.

A talk on Typescript would be interesting to more people than you might think, but a talk on your experience using Typescript for the first time and the things you learned as part of that experience will be interesting to nearly everyone, even if they aren’t interested in Typescript itself. Every software developer has had the experience of using a new language on a project. Experienced Typescript developers are interested in the problems people new to the language face. People interested in learning Typescript will be interested in your experience. You have something to say that people will want to hear!

If you are worried about writing about something for fear that you will say something wrong and be called out for it, no one can correct you about your own experiences. If you want to give a talk but are worried that someone in the audience will contradict you, it’s important to remember that by being the person standing on the stage giving the talk, people will assume that you know what you are talking about.

While putting yourself out into the world can be scary, reminding yourself of the above may help you overcome that fear. Remembering that you can build up your experience in many small ways is also key. Very few people have their first public speaking experience in front of hundreds of people or have their first blog post go viral (for the wrong reasons).

Why do I write and talk?

Every person will have their reasons for wanting to share their knowledge publicly. I have several reasons why I choose to.

To share knowledge

Over the decades, I’ve gained a lot of hard-won knowledge and learned a lot from others who have been generous with their wisdom. I try to share what I’ve learned with my teams and the people I mentor, but widely sharing knowledge takes a long time. Posting and giving talks is a faster way of sharing the lessons I’ve learned.

To save time

In my mentoring, I often find myself repeating the same advice over and over. That will frequently prompt the subject of a new blog post or talk (such as this one). As a benefit of posting it somewhere, I can refer someone to it for more information. It helps me save some time in a conversation. If a person has already read the post or seen the talk, we can focus on the specifics of their issue and get deeper faster.

To understand something better by explaining it to others

Writing a post or talk also allows me to crystallize my thoughts on a subject. So often, we come to a way of doing things over time and don’t consider why we do things that way or how we came to our approach. Writing out how I approach a subject helps me understand myself and why I do things. My decisions became much more deliberate once I started blogging and talking.

Employer Branding

As a leader of an organization, I’m responsible for hiring well. One of the best shortcuts for hiring is for candidates to know how your organization functions. That helps to select candidates who are interested in your way of working and select out those who would be happier elsewhere. The Netflix Culture Deck is a famous version of this. Informing candidates about your company is employer branding. How do you tell them? Blog posts and talks are great ways to do this.

To Meet People

I’m an introvert, and meeting new people is something I need to force myself to do. When I attended conferences, I would hang out with people I already knew or sit by myself. Being a speaker makes things much easier for someone like me. People will approach me because they’ve seen my talk and have questions or comments. Now that I’ve been speaking for years, people approach me before I talk because they saw me speak at a prior conference. It makes things much less awkward for a person like me.

To Find Customers and Learn from Them

We build software for people. Speaking about our product or product development can be helpful information for potential customers. When researching a software product for my company, I often look at the tech talks or technical blog posts from the company’s technology team. I want to know how open they are about their issues, the kind of stack they use, and whom in the company I may want to reach out to if we have questions or a problem (and not have to go through the sales team).

Personal Branding

While many people think this is why most people blog or speak to promote themselves (carrying with it a sense of icky egomania), for most of my friends who are frequent writers or speakers, this is usually the least important reason or not a reason at all. There certainly is a benefit to having your name attached to a well-known talk or often-shared blog post. I’ve been approached for new jobs because people have read something I wrote or seen a presentation that I gave, but this happens far less often than you might think. If your primary reason for writing or speaking is to get “famous,” there are better ways to do that.

How you can get started

Just do it

“All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer.”
? Ira Glass

The best way to do it is to do it. Create a blog. Give a talk to your team. It probably won’t be very good. When you are getting started, you aren’t perfect. It’s a skill like any other. You must develop it; the only way is to do the work. I’m an ok writer. My taste still exceeds my ability, but I write much better today than when I started blogging. My early posts are embarrassing to me now, but I’m glad I wrote them. Otherwise, I wouldn’t have improved at all. I’m thrilled that my earliest talks aren’t on YouTube. They were cringy. Through practice and repetition, I’m a much better speaker now and can give an opening keynote to 5000 people without having a panic attack.

Pedestrian: “How do I get to Carnegie Hall?”
Street Musician: “Practice, Practice, Practice”

Start Small

It’s easy to create a blog. Plenty of free platforms exist to do just that. Create an account and go! Give yourself a goal, such as one blog post monthly if you don’t enjoy writing. One blog post per week if you are ambitious. The trick is to make it a habit. Writing isn’t something I do naturally; I must make myself do it. My posting is extremely infrequent when I don’t have a blogging goal.

You can propose talks to every conference in the world from the day you decide that you’d like to become a speaker. Still, getting started with presentations in your own company or at a local meetup is probably better to build your skills and confidence. They are much easier to get into and more forgiving of inexperienced speakers. Some conferences pride themselves on giving first-time speakers opportunities and coaching. However, I would still look for any opportunities you can to practice giving talks and not count on those. While I haven’t tried it, many people have raved to me about their experiences with Toastmasters International.

Read/Watch

To be a writer, you must be a reader. Find blogs that you like and follow them. They don’t have to be about technology. Read not just for content but for style. You are trying to understand blogging, not just the subject. How do writers you like address their audience? Are they formal or personable? Do they use complicated jargon, or do they try to address wider audiences? Understanding what resonates with you in the writing of others will help you inform your style. It also helps you to understand the conventions of the medium so that you can embrace or ignore them (as you wish). Every YouTube video says some version of “hit the subscribe and like buttons,” for example.

Watch recorded talks from conferences, and find the presenters you like. How do they structure their talks? How do they organize their slides? How do they involve the audience? Similarly, what are the conventions? What things do you want to adopt or ignore? I can say that when I was trying to improve as a speaker, I would try to adapt cool things I saw other speakers do. I still do some of those things, but have found my version. Great artists steal, but eventually, you should find your version of an approach.

Build Up

As I said above, improving writing involves writing as often as possible and reading as much as possible. Improving speaking also requires repetition, but it is harder to find public speaking opportunities.

Giving talks within your company or local meetups will be easier than at national or international conferences. If you feel comfortable and want to grow your experience, expand your subject beyond technology. Find opportunities to give talks about your favorite hobbies. Try different structures, like Pecha Kucha or PowerPoint Karaoke.

You could also write talks and record them, then post them to YouTube.

Once you have some experience and gained some confidence, you can start applying to speak at conferences. Some excellent resources for CFPs are linked below (Call for Proposal/Participation/Papers). Writing talk proposals is a skill in itself, but it will also benefit from practice. If you feel strongly about a talk idea, try writing the proposal for it in different ways. Do your best to tailor your proposal to the conference. Reference the prior year’s schedules to know the kinds of talks the organizers prefer and what successful proposals look like.

Be patient and persistent. It may take many submissions before your first conference talk is accepted.

Your talk was accepted!

Congratulations! It’s exciting and a bit scary. If the conference offers coaching or speaker preparation meetings in advance, take advantage of them! It’s an excellent resource for an inexperienced speaker.

Different people have different processes for preparing for a conference talk. What works for one person may not work for you. I will describe how I prepare; you can try my method. Feel free to adapt it and make it your own.

I often write my proposals based on ideas I have. Once one of them is accepted, I will sit down to write the actual talk. I usually start with an outline. It is usually far too long for the time I have to give the talk, but it is easier for me to remove content than to add it. I typically budget for one slide per minute. For a thirty-minute talk, I will expect to need thirty slides. I don’t necessarily spend the same amount of time on each slide; it just helps me set my expectations.

I don’t focus on making the deck too pretty at first. I want to get the content and some initial timing correct. Once I complete the first draft, I will try giving the talk to see how it flows. Often, that will help me identify extraneous or missing elements. I then refine the deck, try giving the talk again, and further refine it. I may go through many passes of practicing and refinement before I feel comfortable with the flow and content. As the talk feels more “solid,” I will pay more attention to the timing. Am I close to the desired length? A bit over or under is easy to fix, but if the talk is far too long or short, I will need to make some more radical changes.

Once the content and length are close to where they need to be, I will focus more on the structure of the slides. I will break up slides so as not to have “walls of text,” or I may move the text off of the slide entirely and move it to the speaker notes.

Once the design and structure of the slides feel right, I will continue to practice to get a sense of the timing for each slide. I want to have a rough timing in the speaker’s notes to know if I’m getting behind or ahead of where I expect to be when presenting.

Finally, as the day of the conference approaches, I will continue to practice the talk. I don’t want to memorize; I may want to remember some key phrases, but I want to have the structure of the talk memorized. On multiple occasions, the projector or presentation computer has failed, and I’ve given my talk without slides, adapting the message and content to the lack of visuals. It gives me confidence that, as a speaker, I know my presentation. Because I don’t memorize it, I can adapt my words to address members of the audience or refer to earlier talks without worrying about losing my place.

A Secret about Speaking and Giving Talks

The more you do it, the more you’ll be invited to. I still submit CFPs for conferences I am anxious to speak at or haven’t spoken at before, but about half or more of the talks I give are now at the organizers’ invitation because they have seen me speak before.

Similarly, while I continue to publish on sites I control, I get many more invitations to contribute to larger sites because the editors have read something I have published elsewhere.

I wish you the best of luck on your writing or speaking journey!

References

Big day today!

The book is now available from stores worldwide! E-book, hardcover (amazon-only), and softcover! The audiobook will be available soon as well.

If you’ve appreciated what I’ve been sharing in this newsletter and the podcast, please consider buying a copy.

https://itdependsbook.net/

Amazon, Bookshop.org, Barnes & Noble, Thriftbooks, Kobo, Booktopia, Foyles, and many other locations!