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.

Unlocking Potential: Mentoring vs. Coaching

In our professional lives, growth is a constant pursuit, not merely for our development but also for the organizations we represent. We’re all learning all the time, albeit in different ways and at varying paces. In nurturing an employee’s growth within a role, two approaches frequently come to the fore: mentoring and coaching. While both are powerful tools, they serve different purposes and are best applied in specific contexts – sometimes, we need a guide, and sometimes we need a goal-oriented strategist.

Choosing the Right Approach: Context is Key

“Coaching is for performance. Mentoring is for potential.”

The choice between coaching and mentoring hinges on the context. Here are some hypothetical situations to illustrate this.

Consider an employee who is a subject-matter expert, consistently delivering quality work but struggling to make presentations to stakeholders. In this case, a coach could help the employee improve their communication and public speaking skills, with clear, measurable objectives for their progression.

In contrast, imagine a new recruit with immense potential but little experience in the industry. With their wealth of experience and industry knowledge, a mentor could provide this newcomer with invaluable insights about the sector and career development advice, supporting their long-term growth.

When explaining the difference, I often contrast these roles by saying, “With mentoring, I will give you my opinion. With coaching, I will ask you the questions necessary for you to form your own approach with my guidance.”

The mentoring approach works better for more experienced professionals expanding their skills to new areas. The coaching approach is better for someone who needs to deepen their skills in an existing area. Coaching is also effective when helping someone in an area where you don’t have as much direct experience. You can leverage your experience in other areas to help the person figure out the answer themselves.

Be explicit in your choice of method

Know if you are taking a coaching stance or a mentoring stance when helping someone. That does not mean you can’t give advice when coaching or ask prompting questions when mentoring. It means you and the person you are working with understand how you will approach the interaction. It sets the tone and expectations.

Enhancing Your Approach: Continuous Learning

To delve deeper into the nuances of coaching and mentoring, a few resources come to mind. For books, “Coaching for Performance: GROWing Human Potential and Purpose” by John Whitmore and “One Minute Mentoring: How to Find and Work With a Mentor – And Why You’ll Benefit from Being One” by Ken Blanchard and Claire Diaz-Ortiz offer practical insights into each approach’s core elements.

Embrace the Journey of Learning

“Mentoring and coaching are not an ‘either-or’ proposition but a ‘both-and’ necessity.”

While mentoring and coaching have unique strengths, it’s essential to recognize that both are integral to fostering a growth culture in an organization. The mentor-mentee relationship builds a knowledge-sharing culture, and coaching empowers individuals with specific skills to excel in their roles.

In our pursuit of growth, remember that we’re not merely ticking off a checklist. We are on a journey that requires us to understand when to take the scenic route of mentoring, appreciating the broader view of the professional landscape, or when to go straight ahead with coaching, focusing on the immediate roadblocks ahead.

Remember to share your insights and experiences as you continue on this journey. We are all co-travelers in this quest for growth and learning; every insight contributes to the collective wisdom.

My Belated 2022 Recap: Podcasts

Previous posts cover the books and blog posts I found valuable this year. This post covers the podcast episodes that I wanted to share.

InfoQ – Phil Abernathy on Employee Happiness and the Bureaucracy Mass Index

https://www.infoq.com/podcasts/employee-happiness-bureaucracy-mass-index/

In this Shane Hastie, Lead Editor for Culture & Methods, spoke to Phil Abernathy about his work helping organizations focus on employee happiness to drive customer happiness and shareholder return and the Bureaucracy Mass Index as a tool to identify where companies are bloated and ineffective. He also spoke about what’s needed for real transformation.

Great practical advice on building happier teams and a tool to measure bureaucracy in an organization.

A Brief History of the Metaverse: DIY Metaverse

A Brief History of the Metaverse: DIY Metaverse

Tony and Mark – supported by a global community of technologists, enthusiasts, and dreamers – brought 3D to the brand-new Web with VRML. This episode features Owen Rowley, Neil Redding, Linda Jacobson, Brian Behlendorf, John McCrea, Coco Conn — and Neal Stephenson.

With all the talk (and investment) in the metaverse, it is frustrating sometimes that people forget that the technology industry has been thinking and working on this for decades. Tony and Mark were instrumental in creating VRML, and I appreciate them documenting some of the history, but I was a bit disappointed that they omitted some of the other folks that were involved in the beginning.

CALLING BULLSHIT – Spotify: Starving Artists?

Spotify: Starving Artists?

Stated purpose: to unlock the potential of human creativity—by giving a million creative artists the opportunity to live off their art and billions of fans the opportunity to enjoy and be inspired by it.

Spotify is the most popular streaming service in the world, with 188 million people paying for premium subscriptions and hundreds of millions more listening for free on the ad supported tier. Which is why it has been called the world’s best place to get noticed as a musician. But getting noticed and making a living are two different things. In this episode we decide if Spotify is more about “Honesty” or “Little Lies?”. Listen in to find out.

One of our board members at Anaconda turned me onto this podcast. It’s about purpose-driven companies that don’t live up to their professed goals. This episode focuses on Spotify but also talks about the broader streaming music economy.

A16z Podcast – Creators, Creativity, and Technology with Bob Iger

https://a16z.simplecast.com/episodes/creators-creativity-and-technology-with-bob-iger-L98rXqw2

A wide-ranging conversation with Bob Iger on the interplay between technology, content, and distribution; as well as Bob’s journey — and that of various creators! — especially as the industry evolved from TV and cable to the advent of the internet/ web 1.0 to 2.0 to briefly touching on web3 and other emerging technologies. As well as topics top of mind for all company and community builders: from build vs. buy and the innovator’s dilemma, to managing creativity, decentralization, remote work, and much more.

I didn’t expect to like this podcast as much as I did. I appreciated it not only for his takes on leading teams of creative people but also for his business acumen and for getting more details about creative people I admire and their work.

20VC – 20 Product: Marty Cagan on The Four Questions of Great Product Management, Product Lessons from Marc Andreessen, Ben Horowitz and eBay’s Pierre Omidyar & The Difference Between Truly Great Product Teams and the Rest

20 Product: Marty Cagan on The Four Questions of Great Product Management, Product Lessons from Marc Andreessen, Ben Horowitz and eBay’s Pierre Omidyar & The Difference Between Truly Great Product Teams and the Rest

Marty Cagan is one of the OGs of Product and Product Management as the Founder of Silicon Valley Product Group. Before founding SVPG, Marty served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett-Packard, Netscape Communications, and eBay. He worked directly alongside Marc Andreesen and Ben Horowitz at Netscape and Pierre Omidyar at eBay.

I was not a fan of Cagan’s book Inspired. I called it “Ayn Rand for Product Managers.” I worked with some product managers who were all huge fans of it, and the result was not great for working with engineering.

In the time since, I have appreciated what Cagan said in his blog, which was a lot more focused on Lean-style product development and cross-functional collaborative teams. This podcast was further evidence for me that I need to re-evaluate how I see Cagan. I appreciated his perspective.

Planet Money – Episode 576: When Women Stopped Coding

https://www.npr.org/sections/money/2016/07/22/487069271/episode-576-when-women-stopped-coding

Mark Zuckerberg. Bill Gates. Steve Jobs. Most of the big names in technology are men.

But a lot of computing pioneers, the ones who programmed the first digital computers, were women. And for decades, the number of women in computer science was growing.

But in 1984, something changed. The number of women in computer science flattened, and then plunged.

Today on the show, what was going on in 1984 that made so many women give up on computer science? We unravel a modern mystery in the U.S. labor force.

This podcast was oddly personal for me. It talks about how advertising and culture perpetuated a vision of computers as being for boys, discouraging women from entering the computing field. This was the time that I became fascinated by computers. I remember the ads, tv shows, and movies they discuss, and when I entered college for Computer Science my class was 70 men and 2 women. They also talk about my alma mater Carnegie Mellon and the steps that they have taken to address this imbalance.

It is amazing how quickly culture changed computing from being a female-dominated field to being a male one and then how long it has taken us to try and bring it back into some sort of equilibrium.