It Depends: Lessons in Technology Leadership

A CTO needs to hire more engineers, and the numbers are working against the argument. Engineering spend has fallen as a share of revenue because the company grew faster than the team, so on paper it looks like efficiency. In practice, one resignation could sink the roadmap. Kevin Goldsmith's advice was to stop arguing from within and examine the organization as an acquirer would.

Kevin has led due diligence as an acquirer at large companies and startups, and he's been examined as a target through acquisitions and investor rounds. From both seats, the same pattern keeps showing up: the organizations that come through well are the ones whose leaders already know where the problems are and have a plan for them. The catch is that the longer a leader has been in an organization, the less its workarounds look like problems.

The framework here is the Outsider's Audit, four questions anyone doing diligence will ask, turned on your own team: Worth, Dependencies, Flow, and Risk. Kevin walks through each one practically, including building spare capacity at the org level so a resignation doesn't cancel a quarter of work, tracing a single ticket to find where work actually stalls, trading audits with a peer, and handling the people side, right up to the moment the team starts wondering if the company is being sold.

The episode is aimed at CTOs and VPs who may face funding or acquisition diligence someday, but the approach works just as well for a director or engineering manager who needs to make the case for their team with evidence rather than instinct.

A vendor the security team wanted, budgeted two years in a row, and never actually bought. When Kevin Goldsmith finally tried to spend the money, his CFO asked what the ROI was, and he didn't have an answer good enough to win the argument. Not long after, a new board arrived and told him he was underinvesting in cybersecurity. Same company, same customers, same risk, completely different verdict.

Every technology leader owns budgets where the best possible outcome is that nothing happens. Security, compliance, reliability, backups, disaster recovery. They're the easiest money in the company to cut and the hardest to defend, because success looks identical to having never spent the money at all. This episode is about how to decide how much to spend, and how to defend the number when finance asks.

Kevin lays out four price tags that other people are already attaching to your risk: the deal price your customers set, the insurance price your insurer sets, the compliance price regulators set, and the survival price you have to estimate yourself. He compares three companies where the right answer ranged from a large security team to a fraction of one person, revisits COVID as the disaster recovery test nobody scheduled, and covers the failure modes that show up again and again, including the raided line item and the backup nobody has ever restored from.

Useful for CTOs, VPs of engineering, and directors heading into a budgeting cycle who need a defensible number rather than a benchmark, and for anyone who has been told in the same year that they're spending too much and not enough.

A developer builds a working replacement for an internal platform over a weekend using AI tools, then asks leadership why they can't ship it on Tuesday. The code is clean, the architecture is real, and the team is confused about the holdup. Kevin Goldsmith explores what happens when AI-powered development speed outpaces the organizational guardrails that once kept teams aligned.

This episode explores the tension between team autonomy and organizational coherence in an era when building software has become dramatically faster, but deciding what to build has not. Kevin draws on Spotify's aligned autonomy model, his own experience watching founder-speed culture collide with a growing engineering team, and a practical framework he calls the Blast Radius Test: three questions that help teams determine whether a decision is theirs to make or requires a wider conversation.

The episode also tackles the blurring line between prototypes and MVPs. When an AI agent produces a prototype with clean architecture, test coverage, and error handling, the output can look identical to a first production implementation. Kevin makes the case that the distinction now has to come from intent and organizational readiness rather than code quality, and shares a story about handing a team his own prototype only to watch them spend weeks trying to ship his throwaway code.

This is for engineering leaders trying to figure out how to give teams room to move fast without losing organizational coherence.

The spreadsheet says building is cheaper now, and the spreadsheet isn't wrong. A vendor's annual license on one line, a couple of developers and some tokens on the other. What that comparison leaves out is that building has always had two costs, and AI only made one of them smaller.

Kevin has spent most of his career firmly on the buy side, with a mantra he gave his teams for years: don't invent things that already exist. This episode is him revising that position rather than abandoning it, and being specific about how much smaller the revision is than the enthusiasm in the industry suggests.

He walks through a four-question test to run before agreeing to build something that already exists, covering blast radius, ownership cost, differentiation, and whether there's an exit path. Along the way: where building genuinely does make sense now, where it still doesn't regardless of how cheap it has become, the license cost trap that catches CFOs, why supply chain risk has started cutting in both directions, and the version of this decision that shows up in headcount instead of software. Two stories anchor it: an auth decision that gave back every dollar it saved and came within about a month of being much worse, and a build made deliberately with an exit already planned.

Chapter 3 from It Depends: Writing on Technology Leadership 2012-2022

In this episode, we discuss my experience building an exercise to better understand what is important to me in a role or company, and how I used the results to prepare for job interviews. I also discuss some of the mistakes people make when interviewing for roles during a downturn, particularly in how they present themselves. If you're currently looking for a job, or think you will in the future (we all will), this episode will be helpful.

Some links:

This chapter discusses what you can do as a manager to protect your team from layoffs: Ensure the team is aligned with company goals. Raising the visibility of the good work of the individuals on the team. Managing performance. All of these things will help when someone is deciding whether anyone on your team should be laid off. This episode provides more information for individuals and explains that managers are judged more by their team's work and less by their own contributions.

Links:

Teams create their own languages organically, which is essential to team bonding and belonging. Understand this and use it to improve how your team works together and make onboarding new members easier.

Links:

A room full of managers agrees on a better way to do something. Everyone nods. Six months later, every team is still working exactly the way it did before. The idea was sound. Nobody had to change, so nobody did.

That gap is the subject of this episode: driving change across teams you don't manage and can't order around. Kevin Goldsmith calls it managing sideways, and it runs on influence without authority, one of the most useful leadership skills and one of the hardest to build. He works through why the two obvious moves, forcing it yourself or getting an executive to force it for you, tend to produce shallow and short-lived compliance, and why being right turns out to be the cheap part of the problem.

The center of the episode is a four-move approach Kevin calls Adoption Without a Mandate: start with the team that already wants the change, frame it as removing their work rather than adding to it, let the first team's results pull in the next one, and settle ownership before the thing scales. He grounds it in two of his own projects, a company-wide career framework he built at Spotify by assembling a coalition, and an early effort at Adobe, where he forced a team to comply and was still paying for it long after the project shipped.

It's a practical episode for engineering leaders at any level who keep hitting the same wall, where everyone agrees on the right thing, and still no one does it. Kevin closes with a short exercise that listeners can run this week on whatever cross-team change they've been pushing.

Some of the most valuable people in any company are those who consistently deliver. Their teams are healthy, the feedback is good, and the reward for all that reliability tends to be the same thing every time: more work, rarely more authority. Kevin Goldsmith calls this the reliable team trap, the point where being trusted to execute quietly stops translating into being trusted to decide.

Kevin works through why it happens, drawing on seven years he once spent running a project that kept succeeding without ever advancing his own career, plus two leaders he currently mentors whose situations played out very differently. The throughline is uncomfortable: if you are not setting the direction for your part of the organization, someone above you is, which means leadership hears their framing of your work instead of yours. That, he argues, is the real difference between running an organization and leading one.

From there, he lays out four moves to close the gap between being measured on output and being measured on judgment: show the thinking, build the bench, claim the contribution, and take a position. Three of them are about visibility, and one is about capacity, and he is direct about why you need both, and why working even harder is the one response that reliably makes the trap worse.

It is aimed at engineering managers, directors, and senior leaders who deliver well and keep wondering why the direction-setting conversations seem to happen without them. Reliability is the floor. This episode is about making sure it does not become the ceiling.

Most leadership advice is about how to have a hard conversation. Far less of it is about when. In this episode, Kevin Goldsmith argues that the when is usually where things break, and that the conversations leaders end up regretting are rarely the difficult ones they had. They're the easy ones that they kept postponing until they weren't easy anymore.

This episode makes the case for the earlier, smaller, cheaper version of every difficult conversation, the one most leaders talk themselves out of by insisting they don't have enough information yet. Kevin draws on two of his own misses, including a senior engineer at Adobe, whom he lost because he avoided a confrontation with other developers on the team, and a prioritization conflict at his first CTO job, which he let run until the CEO noticed and got involved.

At the center is a practical test: five signals that tell you a conversation is already overdue. Pattern, distance, workarounds, cognitive load, and inflation. If two or more are present, the decision to speak up has already been made, and the only thing left to negotiate is how expensive the wait becomes.

It's a short episode with a single, useful idea for anyone who manages people and has caught themselves waiting for the right moment that never quite arrives.