Tech Debt Is a Signal, Not a Sin

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

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

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

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

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

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

Tech debt as a leadership problem

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

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

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

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

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

Four kinds of tech debt

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

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

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

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

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

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

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

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

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

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

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

Why teams get stuck

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

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

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

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

Making better tech debt decisions

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

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

A few practical heuristics help:

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

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

The human layer

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

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

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

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

How to apply this tomorrow

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

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

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

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

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

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

Tech debt as a diagnostic

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

Tech debt is code telling you a people story.

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

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

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

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

Reading the Signal

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

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

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

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

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

What Really Happens in a Board Meeting

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

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

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

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

The Board Meeting Is the Company’s Performance Review

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

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

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

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

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

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

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

Not All Boards Behave the Same

Boards vary widely depending on the company’s stage.

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

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

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

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

What Actually Happens in the Meeting

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

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

A typical meeting looks something like this:

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

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

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

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

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

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

The CTO’s Seat at the Table

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

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

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

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

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

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

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

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

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

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

What the Board Really Pays Attention To

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

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

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

Managing the Human Side

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

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

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

After the Meeting

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

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

That distinction matters more than people think.

What to Take Away

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

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

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

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

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

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

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

Crafting a Technical Strategy That Actually Works

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

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

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

Why documenting a strategy matters

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

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

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

What a good strategy looks like

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

A useful strategy has a few characteristics:

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

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

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

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

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

Start by working backwards

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

If everything were going well two years from now:

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

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

1. Moving toward event-driven architecture

2. Eliminating or isolating legacy systems

3. Prioritizing observability

4. Making large structural changes like cloud migration

5. Reorganizing teams around more scalable patterns

6. Reskilling people as technology evolves

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

Don’t create strategy in a vacuum

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

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

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

Communicate relentlessly

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

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

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

How you know the strategy is working

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

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

Product partners should understand why certain internal work matters.

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

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

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

Final thought

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

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

Originally published in my newsletter on November 16, 2025

Making Technology Choices That Last

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

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

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

Curiosity with Discipline

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

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

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

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

Knowing When to Pay Attention

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

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

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

Use the Curiosity Around You

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

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

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

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

Evaluating What You Find

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

Start with questions:

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

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

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

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

Managing the People Side

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

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

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

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

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

How to Adopt Deliberately

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

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

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

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

Building a System for Technology Choices

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

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

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

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

Closing Thought

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

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

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

Originally published on my newsletter on November 02, 2025

The Hidden Architecture of Engineering

Practical Lessons in Organizational Design

Introduction

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

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

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

Inheriting the System

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

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

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

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

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

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

Designing for Purpose, Not Precedent

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

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

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

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

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

Diagnosing What’s Broken

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

My favorite diagnostic tool is simple: follow the work.

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

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

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

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

Lessons from Team Topologies

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

They identify four core team types:

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

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

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

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

Common Patterns and Traps

Most organizations follow predictable patterns as they grow.

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

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

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

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

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

Reorgs as Refactors

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

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

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

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

Reorgs should feel like system refactors, not revolutions.

Leading by Design

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

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

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

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

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

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

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

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

Values -> Culture -> Everything

A practical guide to recognizing, protecting, and finding the right organizational culture

In this post, I’m revisiting a keynote I gave in 2013 at the BBC Developer Conference, titled “Building a Strong Engineering Culture.” Twelve years later, my thinking has both stayed the same and evolved. I want to discuss culture, not just for engineering teams, but for you as an individual, as a manager, and as someone seeking your next role.

What Actually Is Culture?

Culture’s a heavy word. We use it in many contexts, including company culture, engineering culture, and team culture. But what does it really mean?

Henrik Kniberg, whom I had the immense pleasure of working with at Spotify, distilled it beautifully:

“Culture is the stuff people do without noticing it.”

My definition is more formal: Culture is the manifestation of the shared values of the organization as represented by the actions of its members.

The key words here are values and actions. It’s not what you say, it’s what you do. And to Henrik’s point, it’s what you do without even thinking about it.

Real Values vs. Aspirational Values

Every company I’ve worked at has had its values spelled out somewhere. The problem? Many companies have publicly stated values that aren’t really their values. These are what I call ‘aspirational values’ – they are the values the company wishes to have or believes it should have, but they may not necessarily reflect the actual behaviors and beliefs of the employees.

How do you know what your current team or company’s actual culture is? Scott Berkun created a great test:

“Can an employee say no to a decision from a superior on the grounds that it violates a core value?”

If your company has a core value of honesty to customers, and your boss tells you to lie to a customer, could you say, “I’m sorry, I can’t do that. That doesn’t align with our core values”? And would your boss fire you, give you a poor review, or say, “I don’t care, do it anyway”? If so, it’s not actually a core value.

Think about what the real values of your company are. Not the stated values, the real ones. In companies where the stated and real values matched, those values would become shorthand. Someone would say “That wouldn’t be aligned to [value]” in a meeting, and it would just end the discussion. No disagreement, no argument.

Another way to think about this: if your team shares an office, where’s the thermostat set? Has everyone determined the temperature that they agree on? A new person enters, tries to change it, and somebody says, ‘Whoa, no. This is the temperature we work at.’ That’s a shared value in action. It’s not an important one, but it’s the same principle for how you approach coding or organize your work. This is a simple example of how shared values can manifest in everyday actions, from the way you dress to the way you communicate.

The Flow: Values -> Culture -> Everything Else

Your values create the basis of the culture. The culture then influences everything else:

Processes: How work gets done, or how you account for vacation time, and expenses.
Artifacts: Physical things like signs, swag, and how offices are decorated. At Microsoft, receiving the “Ship It” award upon shipping your product was a significant achievement. It reinforced the core value of delivering value to customers.
Rituals: Company and team meetings, how you celebrate, or how you bring teams together.
Beliefs: What you believe about the industry, about product development, and building successful companies.

Why Culture Matters

You’ve probably heard the quote attributed to Peter Drucker: “Culture eats strategy for breakfast.” I agree with the general sentiment, but I’ve seen plenty of companies with great cultures that struggled as businesses, as well as successful companies with punishing cultures. Patty McCord, former head of HR at Netflix, said it better: “Culture enables success, but it does not cause success.” A great culture helps you go faster, happier, and healthier. While an amazing culture alone won’t guarantee success, it will make things a lot harder without it.

Protecting and Reinforcing Your Culture

If you have a good culture, you need to protect it. Your culture and values must inform every process and framework that guides the company’s operations. Otherwise, you’re creating conflict within the organization between what you say and what you do. If you reward something other than the culture, the culture will shift to the behaviors and values that you reward.

Start With Your Career Ladder

I get particularly frustrated when companies adopt another company’s career ladder. You’re two different companies with two different cultures! Hopefully, that other company designed its ladder to support its values. If your values aren’t aligned with theirs (they aren’t), you’ll start promoting, hiring, and rewarding based on another company’s values.

Build your own career ladder based on your values. It’s a tremendous first artifact because it informs everything else, from how many levels you have (which affects promotion frequency) to the expectations at each level.

Hiring Is Critical

Who you hire either supports or hurts the culture you have. I don’t suggest requiring “perfect” alignment or becoming a monoculture; you need diversity of thought. However, if you have a core value of collaboration and you hire someone who prefers to work alone, dislikes collaboration, and produces good work independently, you have problems.

One: they’ll be unhappy because people keep wanting to collaborate. Two: if they stay and receive raises or promotions, it sends a strong signal that collaboration isn’t actually a core value. Three: if they end up in interview loops, they will be looking for people like them due to similarity bias, which will accentuate the problem.

Onboarding Matters

You can’t simply throw new hires into a team and expect them to pick up the culture. At Spotify, when someone joined, they would spend a sprint with all the people who joined on the same day, plus a few experienced Spotify folks: an agile coach, a development lead, and a product manager. They would build features together and ship them. They would learn why the company did things in a specific way.

Because those new joiners would end up in different parts of the organization, they’d reinforce and refresh that cultural understanding. If a team started to drift, they’d help steer it back.

This intro sprint was also an excellent opportunity to identify if someone wasn’t aligned with the company values. Better to know in the first sprint than months later.

Performance Reviews and Firing

When deciding an employee’s performance as a manager, your reference isn’t other employees; it’s the rubric, the career ladder. What are they supposed to be doing? What is the expectation at this career step? You’re comparing them against the rubric because your culture and values inform the rubric.

If you don’t use that as the yardstick, you start promoting or giving raises based on something else. People notice. I’ve heard “My friend in another team got promoted and they’re way worse than me, so why am I not getting promoted?” more times than I can count. That usually means management is not being consistent.

Can you make hiring mistakes? Absolutely. When it becomes apparent that someone isn’t aligned, even if they’re fun to be around and do adequate work, they will erode your culture. You have to make a decision. It’s better to move them along where, honestly, they’ll be happier. If you aren’t aligned with your company’s culture, it’s not a happy place for you.

Team Culture vs. Company Culture

I used to think Microsoft had a broken culture. I spent eight years there. I was happy for about one or two of those. But the problem was that I wasn’t well aligned with Microsoft’s culture. Nothing was wrong with Microsoft; I wasn’t a good fit for the company culture.

I tried to make my team work the way I wanted the company to work. I convinced my management to let me build a team and use extreme programming to deliver a feature. The project was incredibly successful. When I went back and said, “Look, it worked, can we do more?” my boss said, “You’re absolutely right, it worked better than we expected. However, no, we’re not going to do that anymore because that’s not the way the company works.”

He was right. That wasn’t who Microsoft was. I wanted to turn the company into the place I wanted to be, but that wasn’t what the company wanted.

If you’re hoping your team can change the dominant culture, good luck. It’s unlikely, especially in larger organizations. It isn’t impossible, but it’s very, very difficult.

I had a different experience at Adobe. Adobe was open to change, not fixed in its mindset. When I worked on a lean, startup-like project there and succeeded, Adobe rewarded that success rather than saying, “Wow, that was great, we’re never doing it again.” Adobe had a core value (stated or not) of being open to change. That was much in line with who I am, and I was very happy there.

When Culture Shifts

Culture isn’t fixed. It will evolve with the company and its employees, sometimes slowly, sometimes quickly.

Slow, Organic Change

Organic change happens naturally. Companies grow, expand into new markets, and hire new employees. Over time, the culture will change to incorporate the new shared values and new processes required to support the larger entity. That’s okay if you’ve been careful in your hiring to ensure that new hires align with the company’s core values.

If the company’s core values are genuine, they will endure as the company doubles in size, becomes public, or changes its funding models. The culture may shift slightly, but what makes the company the company — the culture — stays consistent.

Fast, Disruptive Change

Fast cultural change occurs when a company is acquired or when the board brings in a new CEO. An acquiring company may have no interest in your culture; they’re buying you for financial or business reasons. Your processes will change to align with them, you’ll inherit their career ladder (and thus their values).

Or a new CEO comes in and says, “This is crazy, we can’t run a company this way,” and starts making changes based on their values. This change is often a deliberate choice from the board to “shake up” a company, or because the board is unaligned with the company’s values.

You often see this in startups. They hire a C-level person from Meta or Amazon, and that person starts implementing things from their prior company because that’s what they know works. An Amazon person says, “We need six-page memos for all meetings because that worked well at Amazon.” It does work at Amazon. Will it always work at your company? No.

You can hire talented individuals from these companies; they have great people there. You need those who are open-minded, who understand their experience was for that environment, and who ask, “How do I take what I learned and apply it in this new context?”

When rapid cultural change occurs, you’re either going to be pleased about it or not. If you’re unhappy, complaining or fighting the change is not a good use of your time. If you’re open-minded and don’t actively hate it, try it out. You might learn new skills or approaches. But if you’re unhappy and unaligned, why are you staying?

There’s a quote from Shanley Kane: “Broken cultures break people.”

Finding a Culturally Aligned Company

If you’re looking for a new job, it’s essential to determine if a company aligns with your values. First, you have to know your own values. What’s important to you? What are your must-haves versus nice-to-haves?

Then develop questions you can ask your interviewers. Ask about what happens when the company is under pressure. What happens when revenue is short for a quarter? What happens when a product is late? If you’re in B2B, what happens when a customer is about to churn? When a company or its leadership is under pressure, that’s when its true values are revealed.

I once joined a company where the CEO told me great stories about fixing broken cultures and the great culture he wanted to build. The team was terrific and shared many of my values, as well as the stated values of the CEO. But when the startup hit a rough patch, we started violating those stated values one by one. When I said, “I’m not going to do what you’re asking because that’s not who we say we are,” and the response was, “I need you to do it anyway,” I knew it wasn’t the right place for me after all.

So, ask for examples of stressful situations and how they affected the company’s operations and processes. If the person you are speaking to can provide concrete examples of how they reacted under stress in ways that align with their stated values, that’s a sign that they are genuine core values.

Final Thoughts

I loved working at Spotify. It’s the best job I’ve ever had. Why? The stated values were the actual values. They weren’t aspirational. That’s one reason I took the risk of moving my family to another continent to work there.

My experience with Adobe was very similar. The core values and culture of both companies were incredibly aligned with my personal values. Not only did that make me a happy employee, but it also made me a successful one, as I naturally worked in a way that was aligned with my peers and management.

Am I happy at my current company? Yes, I am. Because my values align closely with the company’s actual values. Will I be happy forever? It will depend on how the culture evolves.

I hope your company’s values align with yours. If they aren’t, I hope you’re in a position to influence the culture or find a place that’s better aligned with your values. It’s worth paying attention to. It’s worth being aware of. It’s essential to consider this, especially if you’re aiming for professional growth. If the company isn’t aligned with your values, you might learn the wrong things.

To hear an extended discussion of this topic, please listen to my most recent podcast episode: https://itdependspod.com/episodes/values-culture-everything-why-company-culture-actually-matters/

Originally published at https://kevingoldsmith.substack.com/p/values-culture-everything

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.

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!

Logical Empathy

We often hear about empathy as a singular concept—a soft skill, an essential quality of being human that connects us to others. But empathy comes in two flavors. It has shades, and understanding them might make us better humans.

Two Sides of the Same Coin: Logical and Emotional Empathy

– Emotional Empathy: This is the classic definition of empathy that most of us are familiar with. It’s feeling what another person feels. If your friend is sad, you feel sad. If they’re excited, you feel their joy. Emotional empathy happens almost instinctively. It’s raw and visceral.

– Logical Empathy: This form is more calculated. It’s understanding what another person feels without necessarily feeling it yourself. It’s more about perception, awareness, and insight. It’s about seeing things from their perspective, even if you don’t feel their viewpoint.

Emotional empathy might be more natural for some people. You know the type, those who can feel a room’s mood as tangibly as a physical touch. I’ve always admired that, but it wasn’t me.

And then there are others for whom logical empathy might be more innate. These individuals are perceptive, analytical, and capable of seeing a situation from various angles without becoming emotionally entangled. Many of us who make our careers in technology are attracted to the industry because we have these skills.

Learning the wrong lessons early

Most of my first jobs were at large companies with very competitive and hierarchical cultures: IBM, Silicon Graphics, and Microsoft. Microsoft in the 1990s was legendary for its’ hyper-competitive culture. I worked there for eight years. Microsoft taught me that I had to expect that other teams were constantly looking for how to undermine mine and that every outstretched hand was likely masking a knife held in the other hand behind the back. I eventually realized that the environment was a bad fit for me, but sadly, I didn’t get out until I had internalized those lessons.

After Microsoft, I sought out more collaborative environments, but I struggled. I constantly expected ill intent behind every action from a peer. I knew that this was hurting me and that I needed to move to a mindset of expecting positive intent from others, but I didn’t know how to rewire my brain.

A Splash of Insight: David Foster Wallace’s “This is Water”

My epiphany came when someone recommended that I read David Foster Wallace’s commencement address to Kenyon College, “This is Water.” If you haven’t read or listened to it, it’s enlightening. Wallace talks about default settings, the unconscious, automatic ways we interpret everything around us. He speaks about learning to think more compassionately and understanding that everyone around you has a unique inner life full of dreams, fears, and struggles. And it’s not always about feeling their pain; sometimes, it’s about understanding their pain.

Wallace’s speech was a masterclass in logical empathy. And it gave me a better way to try and understand others’ intents, especially when you don’t know someone well.

Developing Logical Empathy When Emotional Empathy Feels Unnatural

So how can you foster logical empathy if emotional empathy doesn’t come naturally to you? Here’s a roadmap:

Listen More, Talk Less: You don’t have to feel what someone else feels to understand them. Listen actively, engage with their words, and seek to understand their perspective.
Ask Questions: If you don’t understand something, ask. Asking not only clarifies but demonstrates that you are engaged and interested in the other person’s perspective.
Seek to Understand Their Context: What could be the pressures on them that they may not be vocalizing? If you are talking to a salesperson near the end of the quota, could they be pressured to make their quota? Is the Product Manager being held to unrealistic expectations by their boss? Leverage what you know about the business or organization to understand what subtexts may be unsaid.
Reflect: Spend time thinking about the perspectives of others. Consider why they feel the way they do. Analyze their thoughts without judgment.
Use Imagination: Try to visualize the scenario from their perspective. This mental exercise helps in understanding without feeling.
Practice Compassion: Logical empathy may not be instinctive, but it’s still a form of compassion. Approach situations and people with an open heart, even if it’s an analytical one.

Embracing Both Forms

The truth is logical and emotional empathy are not mutually exclusive. You can be someone who mainly engages with logical empathy while still having the capacity for emotional empathy and vice versa.

The real beauty lies in embracing both and recognizing that there’s no right or wrong way to connect with others. It’s a journey, and it’s one worth taking, regardless of where you naturally fall on the empathy spectrum.

In our complex and diverse world, empathy in all its shades is more than a desirable trait; it’s a necessity. Understanding how you relate to others and working on enhancing that connection, be it through emotional or logical empathy, makes you not only a better colleague, friend, or partner but a more complete human being.

This exploration of empathy, fostered by wise words from thinkers like David Foster Wallace, has been a personal awakening. It’s water, and now I see it.