Posted on

The Reluctance to Fire Is a Feature and a Flaw

Illustration for The Reluctance to Fire Is a Feature and a Flaw

One of the most persistent patterns I’ve observed across technology organizations is the gap between how quickly leaders *know* someone isn’t working out and how quickly they *act* on that knowledge. In sales organizations, this gap tends to be smaller : performance is measurable, quotas are unforgiving, and the culture around exits is more matter-of-fact. But outside of sales, particularly in engineering and product, the reluctance to fire runs deep. I don’t think this reluctance is irrational. In fact, I think it’s rooted in something real, and understanding why it exists is the first step toward managing it better.

The Hidden Costs That Drive Hesitation

Firing someone, especially in a technical organization, rarely feels like a clean decision. Searches take a long time. Teams invest heavily in hiring : not just recruiter hours and interview loops, but the emotional energy of evaluating candidates, making offers, and onboarding someone new. Once a person joins, replacing them can mean being short-staffed for months, putting projects at risk, and redistributing load onto people who are already stretched. Even if no one says this explicitly, I think many managers feel that cost very acutely. The decision to exit someone isn’t just about that individual ; it’s about the six months of disruption that follows.

Because those costs are high, managers naturally spend more time trying other interventions first:

  • Coaching and mentorship, hoping the person can grow into the role
  • Changing scope or responsibilities, looking for a better fit within the same team
  • Moving someone to a different team or function entirely
  • Lowering expectations temporarily, hoping that reduced pressure will unlock better performance

Sometimes these interventions are exactly right. I’ve seen people who were struggling in one context become strong contributors in another. But I’ve also seen , far more often, honestly , situations where these interventions become a way to delay a conclusion that, in retrospect, was probably clear much earlier. The interventions feel productive because they represent *action*, but they can also function as a sophisticated form of avoidance. The hard part is that you often can’t tell the difference between genuine investment in someone’s development and a slow-motion avoidance of conflict until you look backward.

Culture Sets the Speed

I’ve come to believe that organizational culture is the single biggest determinant of how quickly leaders make exit decisions. If the culture treats firing as rare, exceptional, and somewhat shameful , something that only happens when there’s been a dramatic failure , managers will be slower to do it. They’ll worry about how it reflects on them, whether they’ll be seen as having made a hiring mistake, and whether their peers will view the decision as harsh. If instead the culture treats fast, respectful exits as a normal part of maintaining a high-performing team, managers will make those calls more quickly and with less hesitation. Not because they care less about people, but because the organizational environment has made it clear that acting decisively is expected and supported.

More broadly, like hiring, this is a muscle. If an organization rarely exits people, leaders get less practice at the critical judgments involved:

  • Recognizing the difference between a slow ramp and a fundamental mismatch
  • Distinguishing between someone who needs coaching and someone for whom coaching is unlikely to change the outcome
  • Having the direct conversation early rather than letting ambiguity linger
  • Managing the logistics and emotional complexity of an exit with genuine respect

Organizations that treat exits as a more normal part of operating develop leaders who are better at all of these things. Not because those leaders are less empathetic, but because they’ve built pattern recognition through repetition. They’ve seen what early warning signs actually predict, and they’ve learned that acting with speed and clarity is often more humane than dragging out an uncertain situation for months.

When Optimism Becomes the Problem

One of the harder leadership tradeoffs here is that many of the strongest leaders I’ve known are deeply optimistic about people’s potential. They genuinely want to help someone succeed. They see what a person *could* become and invest their energy in trying to close that gap. That optimism is a real strength ; it’s part of what makes someone a compelling leader, someone others want to work for and with. But it can also create a blind spot. The business doesn’t always have the luxury of waiting for someone’s potential to materialize. Sometimes the role needs a certain level of performance *now*, and the gap between where someone is and where they need to be is too wide to close on any reasonable timeline.

I see this dynamic in my own organization, and it’s something I actively coach against : not the optimism itself, but the failure to balance it against the needs of the business and the rest of the team. When a leader holds onto an underperformer too long out of genuine care for that individual, the cost is often borne by the high performers around them. They pick up extra work, they lose confidence in leadership’s judgment, and in the worst cases, they leave. The irony is that the leader’s compassion for one person can end up undermining the experience of the people who are delivering the most.

I don’t think there’s a formula for getting this exactly right. Every situation has its own nuances : tenure, role criticality, the state of the team, the labor market, the person’s trajectory. But I’ve found that the leaders who handle this best are the ones who separate their belief in someone’s long-term potential from their honest assessment of whether *this role, at this time, in this organization* is where that potential is going to be realized. Sometimes the most respectful thing you can do for someone is to be honest that the fit isn’t right, rather than letting them languish in a situation where they’re slowly failing. That reframe , that speed and directness can be an act of respect rather than cruelty , is one of the more important shifts I’ve seen leaders make over the course of their careers.

Posted on

Frustration is the Result of Mismatched Expectations

Nearly every instance of frustration I’ve experienced in my career, whether my own or someone else’s, has had the same root cause: a misalignment of expectations. Not a lack of effort, not incompetence, not bad intentions. It’s when people operate under assumptions about what should happen, when it should happen, or how it should happen that don’t line up with each other or sometimes with reality. Once I started recognizing this pattern, frustration became less of an emotional dead end and more of a diagnostic signal. It’s telling you something specific, and if you listen carefully, it will often point you directly to the thing that needs fixing.

Understanding What Frustration Is Actually Telling You

Frustration is one of those emotions that feels like it’s about the other person, but it’s almost always about a gap between what you expected and what you got. The tricky part is that expectations are often invisible. We carry them around without articulating them, sometimes without even being aware of them ourselves. A CTO expects the engineering team to flag risks earlier in the sprint. The engineering lead expects the CTO to provide clearer priorities before planning begins. Neither has said this out loud, and both walk away from the same meeting feeling like the other person isn’t doing their job. The frustration is real, but the diagnosis, that someone is failing, is wrong. The actual problem is that the expectations were never shared, never negotiated, and never aligned.

I’ve found it useful to think about expectations as existing in several layers, and misalignment can happen at any of them:

  • Outcome expectations : What does success look like? Are we even aiming at the same target?
  • Process expectations : How should we get there? Does one party expect formal reviews while the other expects autonomous execution?
  • Timeline expectations : When should milestones be hit? What counts as “on time”?
  • Communication expectations : How often should updates happen? What level of detail is appropriate? Who initiates?
  • Role expectations : Who owns what? Where does one person’s responsibility end and another’s begin?

When I’m frustrated, or when I sense frustration building in someone I’m working with, I try to work through these layers methodically. More often than not, the misalignment becomes obvious once you start looking at the specific category rather than the general feeling. The shift from “this person is frustrating me” to “we have different expectations about communication cadence” is enormous. The first framing leads to resentment. The second leads to a conversation.

Why Calibration Is Harder Than It Sounds

Identifying the misalignment is only half the work. The harder part is calibration: actually adjusting expectations so they’re shared and realistic. This is where things get nuanced, because calibration doesn’t always mean compromise. Sometimes it means one party needs to clearly articulate a standard and the other needs to meet it. Sometimes it means acknowledging that your expectations were unreasonable given the constraints. And sometimes it means discovering that the expectations are fundamentally incompatible, which is its own valuable piece of information.

I’ve seen calibration fail most often for a few predictable reasons:

  • Pride gets in the way. Admitting that your expectations were unclear or unrealistic feels like admitting fault, and many leaders would rather stay frustrated than vulnerable.
  • The conversation stays abstract. Saying “we need to communicate better” is not calibration. Saying “I need a two-sentence Slack update every Friday by 3pm on where we stand with the migration” is calibration.
  • Power dynamics suppress honesty. A junior engineer who is frustrated with their manager’s shifting priorities may not feel safe enough to say so directly. As a leader, you have to actively create space for that feedback, because the frustration won’t surface on its own until it becomes attrition.
  • People calibrate once and assume it’s permanent. Expectations drift. Projects change scope. Teams gain and lose people. Calibration is not a one-time event; it’s an ongoing practice.

One scenario I’ve encountered multiple times: a VP of Engineering becomes increasingly frustrated with a senior director’s output, begins documenting performance concerns, and starts down a path toward a difficult conversation about role fit. When I’ve been close enough to these situations to ask questions, the root cause is often that the VP’s expectations evolved, maybe the company entered a new growth phase, or the board started asking different questions, but no one sat down with the director and said, “here’s what I need from you now that’s different from six months ago.” The director is performing to the old expectations perfectly well. The frustration is real, but the performance problem may be manufactured by the lack of recalibration.

Making This Practical

If you take one thing from this, let it be this habit: the next time you feel frustration rising, pause and ask yourself, *what specifically did I expect that didn’t happen?* Write it down if you need to. Then ask a second question: *did the other person know I expected this?* In my experience, the answer to the second question is “no” at least half the time, and often more. That alone changes the nature of the conversation from confrontation to alignment.

When you’re on the other side, working with someone who is visibly frustrated, the same framework applies, though the approach is different. Rather than getting defensive or trying to placate, try asking directly: “It seems like something isn’t meeting your expectations. Can you help me understand what you were hoping for?” This question does two things simultaneously. It de-escalates the emotion by validating it, and it forces specificity, which is where the actual resolution lives. Vague frustration is corrosive. Specific misalignment is solvable.

I won’t pretend this is always easy or that it resolves every conflict. Some frustrations run deeper than expectations: they’re about values, or trust, or fundamental disagreements about direction. But I’ve found that the vast majority of day-to-day professional frustration, the kind that erodes relationships and makes good people dread Monday mornings, comes down to expectations that were never made explicit. The calibration doesn’t have to be perfect. It just has to happen.

Posted on

Define What Good Looks Like Before You Start Measuring

One of the most useful habits I’ve developed as a leader is pausing before any significant initiative, project, or decision to ask a deceptively simple question: what does good look like here? Not great. Not perfect. Not world-class. Just good. It sounds almost too simple to be meaningful, but I’ve found that this single question prevents more dysfunction than almost any other framing I use. Without a deliberate answer, teams drift toward one of two failure modes : either they chase perfection and burn out pursuing diminishing returns, or they unconsciously lower the bar until mediocrity feels like success. Both are corrosive, and both stem from the same root cause: nobody took the time to define the acceptable range of outcomes before the work began.

Good Is Always a Range, Not a Point

One of the nuances that took me years to internalize is that “what good looks like” is never a single number or a single outcome. It’s a range. There’s a bottom below which the result isn’t acceptable : it doesn’t meet the need, it creates risk, or it fails to justify the investment. And there’s a top above which you’re spending more effort, time, or money than the marginal improvement warrants. The space between those two boundaries is where good lives. I’ve seen leaders, especially technically-minded ones, struggle with this because it feels imprecise. They want a target, not a zone. But insisting on a precise target in an inherently uncertain world is how you end up with teams that are either perpetually disappointed or perpetually re-scoping.

Think about it in practical terms. If you’re building a new internal tool, what good looks like might be: it handles the core workflow reliably, it’s adopted by at least 80% of the target users within the first quarter, and it reduces the manual effort by half. That’s the bottom of the range ; below that, you haven’t solved the problem. The top of the range might be: it handles edge cases gracefully, adoption is near-universal, and it reduces effort by 80%. Anything beyond that , say, building an elegant plugin architecture for extensibility that nobody has asked for , is above the range. It’s not that it wouldn’t be nice; it’s that the cost of getting there isn’t justified by the value. Defining both boundaries before you start gives you the ability to make rational tradeoff decisions throughout the work rather than arguing about them at the end.

Why We Lose Perspective

The reason this discipline matters so much is that perspective is fragile, especially under pressure. I’ve watched teams lose their sense of proportion in both directions, and the mechanisms are predictable:

  • Perfectionism creep : A technically excellent team sets out to build something good and gradually raises the bar as they go, because each incremental improvement feels small and justifiable in isolation. Before anyone realizes it, they’ve spent three months polishing something that was ready to ship after six weeks. Nobody made a bad decision at any individual moment, but the aggregate was a significant misallocation of effort.
  • Standards erosion : A team under deadline pressure starts making small concessions. Each one is defensible on its own, but over time the cumulative effect is a product that barely functions or a process that barely holds. They ship something, declare victory, and then spend the next year dealing with the consequences.
  • Anchoring to the wrong reference point : Sometimes teams calibrate “good” against what a competitor has built, or what they built at a previous company, or what they read about in a blog post, without considering whether that reference point is actually relevant to their context, their resources, or their customers. What good looks like for a company with a thousand engineers and a billion dollars in revenue is rarely what good looks like for a team of twenty building their first product.

All of these failures share a common trait: the absence of an explicit, agreed-upon definition of the acceptable range before the work started. When you don’t define the range up front, you leave it to be defined implicitly by whoever has the strongest personality, the most anxiety, or the most influence in the room at any given moment. That’s not a strategy; it’s an accident waiting to happen.

Making This Practical

I’ve found the most effective way to apply this is to make the conversation explicit and collaborative. Before kicking off a meaningful piece of work, I ask the team and the stakeholders to answer three questions together:

  • What is the minimum outcome that would make this investment worthwhile? What’s the floor below which we’ve failed?
  • What is a realistic outcome that we’d be genuinely satisfied with, given our constraints?
  • At what point would further improvement no longer justify the cost , where do we hit diminishing returns?

The conversation itself is often more valuable than the answers. It surfaces misaligned expectations early, before they become conflicts. I’ve seen cases where a CTO assumed the team was building a robust, scalable platform while the product lead assumed they were building a quick proof of concept. Both were reasonable positions, but they were incompatible, and without the explicit conversation about what good looks like, that incompatibility would have surfaced six weeks later as frustration and finger-pointing.

There’s another benefit that’s easy to overlook: defining the range gives people permission to stop. Some of the best engineers I’ve worked with have a natural inclination to keep refining, keep improving, keep making things better. That instinct is one of their greatest strengths, and I never want to extinguish it. But without a clear definition of “good enough for now,” that instinct can become a liability. When you’ve defined the top of the range, you’ve given them a principled reason to move on rather than asking them to accept something they feel is unfinished. It transforms the conversation from “stop caring” to “redirect your caring where it will have the most impact next.”

I’ve also learned that the range needs to be revisited, not just set and forgotten. Circumstances change : new information emerges, constraints shift, the competitive landscape evolves. What good looked like three months ago might not be what good looks like today. The discipline isn’t about rigid adherence to an initial definition; it’s about always having a current definition that everyone understands. The teams I’ve seen operate most effectively are the ones that treat this as a living conversation, revisiting it at natural checkpoints rather than treating the initial definition as immutable.

Ultimately, this practice is about maintaining honesty with yourself and your organization about what you’re actually trying to achieve and what success actually requires. It’s easy, especially for ambitious leaders and talented teams, to conflate good with exceptional and burn resources chasing a standard that wasn’t necessary. It’s equally easy, under pressure, to convince yourself that something subpar is acceptable because you’re tired of fighting for better. The range , honestly and collaboratively defined , keeps you grounded in reality, and reality is where all the value actually gets created.

Posted on

If You’re Doing Their Job, You Need Someone Else in the Role

One of the most persistent traps I’ve seen technology leaders fall into is quietly absorbing the work of someone who reports to them. It starts small: you review a design document and end up rewriting it, or you step into a client conversation because you don’t trust the outcome otherwise. Before long, you’re doing meaningful portions of someone else’s job while still carrying the full weight of your own. The justification is always reasonable in the moment: it’s faster, the stakes are too high, the person just needs a little more time. But if you find yourself consistently doing a subordinate’s job, the honest conclusion is that you need someone else in the role.

I want to be precise about what I mean here, because there’s an important distinction between teaching and doing. Every leader should expect to invest time in developing their people. You’ll pair with them on hard problems, walk them through your reasoning, review their work and offer feedback. That’s mentorship, and it’s one of the most valuable things you can do. What I’m describing is different: it’s when you’ve moved past coaching and are actually producing the work product yourself, or when you’re making every meaningful decision and your direct report is essentially executing your instructions rather than exercising their own judgment. When you’re the one doing the thinking, you’re doing the job.

The Cost Is Higher Than You Think

The most obvious cost is to you. Your time and attention are finite, and every hour spent doing someone else’s work is an hour not spent on the problems that only you can solve. But the less obvious costs are the ones that compound. Your other direct reports notice, they always do, and it breeds resentment or, worse, learned helplessness as they realize that struggling visibly enough will result in you stepping in. The person whose work you’re absorbing stops growing because they never have to confront the full consequences of their gaps. And the organization develops a subtle dependency on you that makes everything more fragile.

I’ve seen this pattern play out dozens of times across different organizations, and the hidden cost that leaders most consistently underestimate is the opportunity cost to the team’s maturity. A team that has a leader perpetually stepping down a level never develops the muscle to operate independently. You might be solving today’s problem, but you’re creating tomorrow’s organizational weakness. The compounding nature of this dynamic is what makes it so dangerous: each intervention feels minor, but over months they add up to a team that cannot function without you in the details.

Why We Let It Continue

If the right answer is so clear, why do smart leaders let this persist? In my experience, the reasons are rarely about the subordinate and almost always about the leader. A few patterns I’ve observed repeatedly:

  • Identity attachment to the work. Many CTOs and engineering leaders rose through the ranks because they were exceptional individual contributors. Doing the technical work or making the architectural decisions still feels like “real work” in a way that managing and developing people sometimes doesn’t. Stepping in feels productive, even when it’s counterproductive.
  • Conflict avoidance. Acknowledging that someone isn’t performing in their role means having a difficult conversation, and potentially making a personnel change. It’s almost always easier in the short term to just do the work yourself than to confront the reality that you’ve got the wrong person in the seat.
  • Misplaced loyalty. The person might be someone you hired, someone you like personally, or someone who has been with the company a long time. Loyalty is a virtue, but not when it comes at the expense of the team, the organization, and frankly the person themselves, who deserves to be in a role where they can actually succeed.
  • Optimism bias. “They just need another quarter.” “Once we get past this project, I’ll invest more in coaching them.” I’ve said versions of these things myself. Occasionally they’re true. More often, they’re a way of deferring a decision we already know we need to make.

Recognizing which of these motivations is driving your behavior is the first step toward honest self-assessment. And honest self-assessment is the prerequisite for making the right call.

Making the Decision and Making It Well

The decision to move someone out of a role is one of the hardest things a leader does, and it should be hard. If it’s easy for you, I’d worry about something else entirely. But difficulty is not a reason for inaction. I’ve found a few principles helpful in navigating this well.

First, separate the person from the role. Someone can be talented, hardworking, and a good cultural fit while still being wrong for a specific position. This isn’t a judgment of their worth; it’s an acknowledgment that the role requires something they don’t currently have, and that the timeline for developing it doesn’t align with what the business needs. Sometimes the right answer is moving them to a different role internally where their strengths are better matched. Not every personnel change has to be an exit.

Second, be honest about whether you’ve actually set them up to succeed. Have you been clear about expectations? Have you given direct, specific feedback about what needs to change? Have you provided the resources and support they need? If you’ve been quietly doing their work instead of having these conversations, then part of the failure is yours. Own that, and then course-correct by having the conversations you should have had months ago. Give people a genuine chance to rise to the challenge, but set a clear timeline in your own mind for when you’ll make the call if things don’t change.

Third, act with both urgency and compassion. I’ve never once looked back on a personnel decision I made too slowly and thought I timed it right. Every single time, I wished I had acted sooner, not because I didn’t care about the person, but because the delay made things worse for everyone, including them. The most compassionate thing you can do is be direct, be fair, and help them land well, whether that’s in a different role or at a different company.

Ultimately, your job as a leader is to build an organization that can execute without you being in the details. If you’re consistently doing someone’s job for them, you’re failing at your own, not because you lack capability, but because you’re applying that capability at the wrong level. The hardest part isn’t recognizing the problem. It’s having the courage to act on what you already know.

Posted on

Leave Every Interaction Better Than You Found It

One of the principles I carry with me into every workday is deceptively simple: leave the world better than I found it. Leave people better than they were before they met me. This sounds like something you’d find on a motivational poster, and I understand the skepticism that might provoke. But I’ve found that when you internalize this as an operating principle rather than a platitude, it fundamentally changes how you show up : in meetings, in one-on-ones, in hallway conversations, and in the quiet moments where no one is watching. It becomes a lens through which you evaluate your own contributions, and it raises the bar in ways that compound over time.

The practical expression of this principle is straightforward: in every interaction, I try to find ways to add value to other people’s lives. Not in a performative way, and not in a way that centers my own expertise or opinion. Simply by asking myself, before and during every conversation, what can I contribute here that makes this better? Sometimes the answer is obvious : I have relevant experience, or I can connect someone to a resource they need. But more often, the answer requires a kind of creative humility that I think many leaders underestimate.

You Don’t Need to Be the Expert to Add Value

One of the most common traps I see technology leaders fall into is silence or disengagement when the conversation moves outside their area of deep expertise. A CTO sits in an architecture review for a system they didn’t design, or joins a product discussion about a domain they’re less familiar with, and they assume they have little to offer. I’ve felt this myself : that momentary sense that you’re just taking up space. But I’ve learned that this instinct is almost always wrong, and acting on it is a missed opportunity not just for you, but for everyone in the room.

Even when the technical subject matter is beyond your depth, there are dimensions of value that are almost always available to you:

  • Ask questions from the customer’s perspective. Engineers and product managers can become so immersed in implementation details that they lose sight of the person who will actually use the thing they’re building. Simply asking “how would a customer experience this?” or “what would this feel like to someone encountering it for the first time?” can redirect an entire conversation in a productive way.
  • Surface risks that others are too close to see. When you’re deep in a problem, you develop blind spots. Someone with fresh eyes , even without domain expertise , can often see risks, dependencies, or failure modes that the team has unconsciously accepted. I’ve found that some of my most valuable contributions in technical discussions have been questions like “what happens if this doesn’t work as expected?” or “have we thought about how this interacts with what the other team is building?”
  • Improve the relationships in the room. This one is underappreciated. Sometimes the most valuable thing you can do is notice that someone hasn’t spoken, and invite them in. Or recognize that two people are talking past each other and gently reframe the disagreement. Or simply validate someone’s concern that others dismissed too quickly. These are not small things ; they shape the health of your organization in ways that compound far beyond any single meeting.
  • Provide context that connects the work to the bigger picture. Teams working on specific problems don’t always have visibility into the strategic landscape. You can add value simply by saying “this connects to something I heard from the board last week” or “the sales team is seeing something similar from a different angle.” Context is one of the most undervalued contributions a leader can make.

The Compounding Effect of Consistent Contribution

What I’ve observed over many years is that this principle, applied consistently, creates a kind of gravitational pull. When people know that every interaction with you will leave them with something useful , a new way to think about a problem, a connection they didn’t have before, or simply the feeling that someone genuinely listened , they begin to seek you out. Not because you’re the smartest person in the room, but because you’re the person who makes the room smarter. There is an enormous difference between those two things, and I’ve found that the latter is far more valuable to an organization than the former.

This also changes how you prepare for your day. Before a one-on-one, I think about what I know about the person, what they’re working through, what might be weighing on them. Before a meeting, I think about the dynamics at play and where I might be able to contribute, even tangentially. This doesn’t require hours of preparation ; it requires intention. And the intention itself is the differentiator. Most people walk into meetings thinking about what they need to get out of them. Flipping that , thinking about what you can put into them , is a small shift in mindset with outsized consequences.

The Honest Tradeoffs

I should acknowledge that this principle has limits and tensions. There are days when you’re depleted, when your own problems are consuming your bandwidth, and the idea of adding value to every interaction feels like an impossible ask. I don’t think this principle should become a source of guilt or self-judgment. It’s aspirational by design : a direction to lean toward, not a standard to be measured against in every moment. There are also situations where the most valuable thing you can do is not contribute: to let a team work through something on their own, to resist the urge to add your perspective when it would only slow things down or undermine someone else’s ownership. Knowing when to step back is itself a form of adding value, though it requires the kind of self-awareness that doesn’t come easily to most of us.

I’ve also seen this principle misapplied by leaders who interpret “adding value” as always having something to say. That’s not what I’m describing. The person who speaks in every meeting, who always has an opinion, who can’t resist inserting themselves , that person is often subtracting value while believing they’re adding it. True contribution sometimes looks like a single well-timed question, or a quiet follow-up message after a meeting, or simply making someone feel heard during a difficult moment. The goal isn’t to be visible ; it’s to be useful.

Over time, I’ve come to believe that this orientation toward contribution is one of the most reliable indicators of leadership maturity. The leaders I most admire are not the ones with the most impressive technical credentials or the most commanding presence. They’re the ones who leave every room a little better than they found it, and who leave every person they interact with a little more capable, a little more confident, or a little more connected than they were before. That kind of leadership doesn’t scale through authority ; it scales through the quiet accumulation of hundreds of small, intentional acts of generosity.

Posted on

Match Your Decision Speed to the Time You Actually Have

One of the most common mistakes I see leaders make is mismatching their decision-making pace to the time available. When there’s plenty of runway, they rush to judgment because decisiveness feels like leadership. When time is short and action is urgent, they freeze up, demanding more analysis, more validation, more certainty before committing. Both instincts are understandable, and both are destructive. The skill worth developing is not simply making faster or slower decisions, but calibrating your approach to the actual constraints you’re operating under.

When You Have Time, Use It

Having time is a luxury, and like most luxuries, it’s frequently wasted. When a decision doesn’t need to be made immediately , when you have weeks or months to evaluate a new platform, restructure a team, or choose a strategic direction , the temptation is to move quickly anyway. There’s a gravitational pull toward early conviction. You form a hypothesis in the first few days, and then everything that follows becomes confirmation rather than genuine exploration. I’ve seen this play out repeatedly with technology selection decisions where a leader falls in love with an option during an initial demo and then spends the remaining evaluation period unconsciously justifying that choice rather than stress-testing it.

When you have time, the most valuable thing you can do is resist premature closure. Work through the details methodically. Validate your assumptions, especially the ones that feel obvious, because those are the ones most likely to betray you later. Talk to more people than you think you need to. Explore the second and third-order consequences of each option. The whole point of having time is that it lets you surface information and perspectives that don’t appear in the first pass. If you’re going to make the same decision in week one that you would have made in week eight, you’ve wasted seven weeks of potential insight.

  • Identify and challenge your earliest assumptions ; they tend to calcify quickly
  • Seek out dissenting perspectives deliberately, not just from people who share your mental model
  • Explore failure modes and edge cases for each option, not just the happy path
  • Revisit your initial framing of the problem ; sometimes the question itself evolves with deeper understanding

This doesn’t mean being indecisive or endlessly deliberating. It means being *thorough* in proportion to the stakes and the time you’ve been given. There’s a meaningful difference between thoughtful patience and analysis paralysis, and it lies in whether your process is generating new insight or just circling the same ground.

When Time Is Short, Act Boldly

Conversely, when time is genuinely scarce , a production incident, a competitive threat that’s materializing now, a key hire you’ll lose if you don’t move this week , the worst thing you can do is apply the thorough, methodical approach that serves you well in longer time horizons. I’ve watched leaders lose critical opportunities because they insisted on the same rigor for a 48-hour decision that they would apply to a six-month initiative. They wanted one more reference check, one more architecture review, one more round of stakeholder alignment. By the time they felt comfortable, the window had closed.

When you have very little time, you need to accept a higher degree of risk and act on incomplete information. This is not recklessness ; it’s *appropriate calibration*. You’re not ignoring risk; you’re acknowledging that the risk of inaction or delay may exceed the risk of an imperfect decision. The key is to make the best decision you can with the information available right now, commit to it fully, and then manage the consequences as they unfold. Hedging, half-committing, or trying to preserve optionality when the situation demands conviction will usually give you the worst of all outcomes.

  • Focus only on the variables that will most materially affect the outcome : ignore everything else
  • Trust your pattern recognition and accumulated experience; this is exactly when it’s most valuable
  • Commit clearly so your team can execute without ambiguity
  • Accept that you may be wrong, and plan to iterate quickly once you see results

One nuance worth noting: acting quickly under time pressure does not mean acting alone. Even in compressed timelines, a five-minute conversation with someone who has relevant context can dramatically improve your decision quality. Speed and collaboration are not mutually exclusive ; but lengthy consensus-building processes absolutely are incompatible with urgency.

The Real Skill Is Honest Assessment

The hardest part of all this is not the decision-making itself. It’s the honest assessment of how much time you actually have. Leaders routinely misjudge this in both directions. Some create artificial urgency where none exists, driven by impatience or a desire to appear decisive. Others fail to recognize genuine urgency because acknowledging it would mean accepting uncomfortable levels of uncertainty. I’ve been guilty of both at different points in my career, and in retrospect the underlying cause was usually the same: I was optimizing for my own comfort rather than for the situation’s actual demands.

A useful practice is to explicitly ask yourself, before any significant decision, how much time you realistically have and what would change if you used more or less of it. If using an additional week would surface meaningfully different information, take the week. If it would just make you feel marginally more confident without changing the outcome, you’re procrastinating under the guise of diligence. Similarly, if you’re rushing toward a decision that doesn’t actually need to be made today, ask yourself what you’re avoiding by not sitting with the uncertainty a little longer.

Over time, I’ve come to believe that this calibration , matching your process to your constraints , is one of the most underappreciated aspects of leadership. We talk a great deal about making *good* decisions, but less about making decisions *well*, which includes the discipline to slow down when you can afford to and the courage to move fast when you can’t. The leaders I admire most are not the ones who are always fast or always thorough, but the ones who seem to instinctively know which mode the moment requires, and who shift between them without ego or apology.

Posted on

Simplicity Is a Leadership Discipline, Not Just a Design Principle

The KISS principle , Keep It Simple, Stupid , originated as a design philosophy, most often attributed to Kelly Johnson at Lockheed’s Skunk Works. The idea was that a jet aircraft should be repairable by an average mechanic in field conditions with basic tools. If the design was too complex for that, it had failed regardless of how elegant it looked on paper. I’ve found that this framing is far more useful than people give it credit for, and not just in software architecture or product design. The principle applies with equal force to how we structure organizations, communicate strategy, and decompose business problems. In fact, I’d argue that the ability to simplify is one of the most underrated skills a technology executive can develop.

There’s a reason simplicity is hard, though. It requires a deeper understanding of the problem than complexity does. Anyone can add layers : more process, more roles, more abstractions, more slides in the deck. Removing layers demands that you truly understand what’s essential and what’s incidental. I’ve seen this play out dozens of times: a leadership team confronted with a messy business problem will instinctively add structure to manage the mess, when what’s actually needed is the courage to cut through it. The best executives I’ve worked with share a common trait : they can take a sprawling, ambiguous situation and reduce it to a small number of things that actually matter. That’s not oversimplification. That’s clarity.

Simplicity in Organizational Design

Org design is one of the areas where the KISS principle pays the highest dividends and is most frequently ignored. When companies grow, they accumulate organizational complexity the way a ship accumulates barnacles : slowly, one reasonable decision at a time, until the drag becomes significant. Every dotted-line reporting relationship, every matrix structure, every committee that exists to coordinate between other committees adds cognitive overhead for the people doing the actual work. I’ve found it useful to periodically ask a brutally simple question: can every person in the organization explain who they report to, what they’re responsible for, and how their work connects to the company’s goals? If the answer is no, your org design has become too complex.

This doesn’t mean org structures should be naive or flat for the sake of flatness. There are legitimate reasons for complexity : regulatory requirements, geographic distribution, the need to balance functional expertise with product alignment. The point isn’t to avoid all complexity but to ensure that every layer of complexity is earning its keep. Some practical ways I’ve applied this:

  • When adding a new team or role, articulate what specific problem it solves that cannot be solved by an existing team or role. If you can’t do this in one or two sentences, that’s a signal.
  • Favor clear ownership over shared ownership. Shared ownership sounds collaborative but in practice it often means no one is truly accountable, and accountability gaps create more organizational complexity down the road as people try to compensate.
  • Revisit org structures at least annually with fresh eyes. What made sense eighteen months ago during a rapid scaling phase may be adding unnecessary friction now.
  • Be wary of creating coordination roles to manage the complexity caused by other coordination roles. This is a classic sign that the underlying structure needs to be simplified rather than managed.

Communicating Strategy with Clarity

The second area where simplicity proves essential is communication, particularly when rolling out new strategies or plans. I’ve observed a pattern throughout my career: the leaders who have the deepest understanding of a strategy are the ones who can explain it most simply. Conversely, when a strategy presentation requires forty-five minutes and thirty slides to convey, it’s often because the thinking behind it hasn’t been fully resolved. Complexity in communication frequently masks uncertainty in thought. This is worth being honest with yourself about : if you can’t explain your plan simply, you may not understand it well enough yet.

There’s a practical dimension to this as well. When you communicate a plan to your organization, every person who hears it will interpret it through the lens of their own role, their own concerns, their own priorities. The more complex the message, the more surface area there is for misinterpretation. I’ve found that the most effective strategic communications share a few characteristics:

  • They can be summarized in a single sentence that captures the why, not just the what. “We’re consolidating from three platforms to one because our customers need a unified experience and our engineers need to stop maintaining redundant systems” is far more useful than a detailed migration roadmap.
  • They use concrete language rather than abstract terminology. “We’re going to reduce our time-to-deploy from two weeks to two days” lands harder and more clearly than “we’re investing in operational excellence.”
  • They acknowledge what’s not changing alongside what is. People absorb change more effectively when they have stable reference points.
  • They’re short enough that a manager three levels down can relay them accurately without a script.

Decomposing Problems to Their Essence

Perhaps the most valuable application of the KISS principle is in problem decomposition. The business problems that land on a CTO’s desk are almost never simple on their surface : they involve competing priorities, technical constraints, organizational dynamics, and market pressures all tangled together. The instinct in these moments is to try to solve the whole thing at once, to build a comprehensive plan that addresses every dimension simultaneously. I’ve learned, sometimes painfully, that this instinct is almost always wrong. The better approach is to break the problem down until you find the smallest meaningful pieces, then solve those pieces in sequence.

This is where the word “stupid” in KISS actually earns its place. It’s a reminder that our tendency toward complexity is often an ego-driven behavior : we want to demonstrate that we understand how complicated things are, that we can hold all the variables in our heads at once. But the mark of genuine expertise isn’t the ability to manage complexity; it’s the ability to eliminate it. When I encounter a problem that feels overwhelmingly complex, I force myself to answer three questions: What is the single most important outcome we need? What is the smallest action that moves us toward that outcome? What can we explicitly choose to ignore for now? Those three questions have saved me from building elaborate solutions to problems that didn’t require them more times than I can count.

Simplicity is not a destination you arrive at ; it’s a discipline you practice. Systems, organizations, and strategies all tend toward complexity over time because every individual decision to add something feels reasonable in isolation. The accumulated weight of all those reasonable decisions is what eventually slows companies down. The executives who keep things simple aren’t the ones who avoid complexity; they’re the ones who are vigilant about pruning it, who understand that every layer they add creates a maintenance burden that extends far beyond the immediate problem it was meant to solve. In my experience, the best technology leaders treat simplicity not as a nice-to-have but as a responsibility : to their teams, their customers, and to the future version of the organization that will have to live with today’s decisions.

Posted on

The Work Never Ends, and That’s Not the Problem

One of the most destructive mental patterns I’ve observed in technology leaders, and one I’ve fallen into myself more times than I’d like to admit, is the belief that relief is just around the corner. If I can just get through this launch. If I can just close this quarter. If I can just navigate this reorg, hire this key person, resolve this production incident, get past this board meeting. Then things will calm down and I can finally breathe.

This thinking feels rational in the moment. It’s a coping mechanism, a way to endure difficulty by promising ourselves a future reward. But it’s fundamentally flawed because it’s built on a premise that almost never holds: that the current pressure is an aberration, and that normalcy, some sustained period of calm, is waiting on the other side.

The Treadmill of Relief That Never Comes

In my experience, the work never ends. Not in any role worth having, and certainly not in technology leadership. The nature of our work is that we’re building things that don’t exist yet, solving problems that haven’t been solved before, and operating in markets that shift constantly. There is no steady state. The moment one major effort concludes, another emerges to take its place. Sometimes it’s already been waiting in the wings; sometimes it materializes from nowhere.

When you orient your entire mental and emotional framework around the idea that you just need to survive until the current crisis passes, several harmful things happen:

  • You give yourself permission to operate in an unsustainable way, burning reserves you’ll need later
  • You defer recovery, relationships, health, and reflection to a future that keeps receding
  • You experience the completion of each effort not as satisfaction but as brief respite before the next wave of anxiety
  • You train yourself to associate your work with suffering rather than meaning

I’ve watched executives operate this way for years, always on the verge of a breakthrough to some calmer existence. They become brittle. Their judgment suffers because they’re perpetually depleted. And perhaps most tragically, they miss the actual experience of their professional lives because they’re always looking past the present moment to some imagined future relief.

Finding Satisfaction in the Process Itself

The alternative is not to pretend the work is easy or that every day is enjoyable. Some days are genuinely hard. Some problems are genuinely draining. The alternative is to recognize that the texture of difficulty is the texture of the work itself, and that meaning has to be found within it rather than after it.

This requires a fundamental reorientation. Instead of asking “when will this be over?” you have to ask “how can I be present in this?” Instead of treating each challenge as an obstacle between you and some peaceful future, you have to see the challenge as the thing itself: the actual substance of what you’ve chosen to do with your professional life.

I’ve found that this shift becomes easier when I focus on smaller units of time. A quarter, a month, even a week can feel overwhelming when viewed as a block to be endured. But an hour? A single conversation? A specific decision? Those can be engaged with fully. Those can be satisfying in their own right, even when they’re part of a larger effort that’s stressful.

  • The satisfaction of helping someone think through a hard problem clearly
  • The small pleasure of writing something well, even if it’s just an internal memo
  • The engagement of debugging a complex issue with your team
  • The connection that comes from being honest with a colleague about a difficult situation

These moments are available constantly, but only if you’re actually present for them rather than mentally fast-forwarding to some future state.

Sustainability as a Practice, Not a Destination

I think many of us treat sustainability as a condition we’ll achieve once external circumstances allow it. We’ll exercise regularly once this project ships. We’ll spend more time with family once we’ve hired the right team. We’ll read more, think more, rest more, later. But later never comes, or when it does, new demands have already filled the space.

Sustainability has to be built into how you operate now, not deferred to some future configuration of your life. This doesn’t mean working less hard or caring less about outcomes. It means recognizing that you’re playing a long game, measured in decades, not quarters, and that how you engage with the work today is how you’ll engage with it for years to come.

The leaders I most admire have figured this out. They’re fully engaged with their work, often in demanding and high-pressure situations, but they’re not waiting for it to end. They’ve made peace with the reality that the work is the thing, and they’ve found ways to be present for it rather than enduring it. They’re not martyrs grinding through until some reward arrives. They’re practitioners who have found meaning in the practice itself.

Every day, every hour, every conversation can be satisfying in its own right if you’re actually there for it. But you have to give up the fantasy that the pressure is temporary and that relief is coming. The pressure is the job. The question is whether you can find a way to be fully alive within it.

Posted on

The Art of Calibrated Effort: Doing Exactly What’s Required

One of the principles I return to most often is deceptively simple: use the minimum amount of effort necessary to achieve the results you want. Not the minimum effort you can get away with, and not maximum effort as a matter of pride, but precisely the right amount. This sounds obvious, perhaps even lazy, but in practice it’s one of the hardest calibrations a leader can make. Most people err dramatically in one direction or the other, either grinding themselves into dust on problems that don’t require it, or convincing themselves that shortcuts won’t catch up with them.

The key word in this principle is necessary. Sometimes the minimum necessary effort is everything you have, every ounce of energy, every late night, every difficult conversation. When you’re navigating a critical product launch, managing a genuine crisis, or building something that will define your organization’s trajectory, half-measures will fail. The minimum necessary might be total commitment. But other times, the minimum necessary is literally zero personal effort because someone else is already handling it, the solution is obvious and doesn’t require your involvement, or the problem will resolve itself if you simply get out of the way. Both of these scenarios demand the same amount of effort from you: exactly what’s required, no more and no less.

The Two Failure Modes

I’ve observed two distinct patterns in how capable people miscalibrate their effort, and both are equally destructive to their effectiveness.

The first failure mode is unnecessary heroics. These are the people who treat every problem as worthy of their full attention and energy. They stay late to perfect things that were already good enough. They insert themselves into decisions their teams could make independently. They research exhaustively when a quick conversation would suffice. On the surface, this looks like dedication, and organizations often reward it because effort is visible while efficiency is not. But this pattern leads to burnout, creates bottlenecks, and paradoxically produces worse outcomes because finite energy gets spread across problems that don’t equally deserve it. I’ve known many leaders who wore their exhaustion as a badge of honor while their most important initiatives languished because they had no reserve capacity left.

The second failure mode is premature optimization—convincing yourself that things require less time, energy, or attention than they actually do. This is the person who ships before the code is ready because testing is tedious. Who has a difficult conversation in their head instead of out loud because it’s uncomfortable. Who skips the stakeholder alignment because they’re confident they already know what everyone thinks. This pattern is seductive because it feels efficient, and sometimes you get lucky and the shortcut works. But the compounding cost of cutting corners is severe: technical debt, broken relationships, misaligned teams, and problems that metastasize while you’re not looking.

Calibrating Correctly

The skill, then, is accurate assessment: understanding what a situation actually requires before deciding how much to invest. Several questions help me make this calibration:

  • What’s the cost of being wrong? High-stakes, irreversible decisions deserve maximum diligence. Low-stakes, reversible ones can tolerate faster, lighter approaches.
  • Who else can or should handle this? If someone on your team is capable and this falls within their domain, your involvement may actively harm the outcome by disempowering them.
  • What’s the real deadline? Not the artificial urgency, but the actual point at which delay causes harm. Many things feel urgent that aren’t.
  • Am I the bottleneck? Sometimes the fastest path is removing yourself from the process entirely.
  • What would good enough look like? Perfection is rarely the standard that matters. Understanding what sufficient actually means prevents both over-investment and under-investment.

These questions sound straightforward, but answering them honestly requires a particular kind of self-awareness. You have to notice when your ego is inflating a problem’s importance, when your anxiety is driving unnecessary activity, or when your discomfort is rationalizing shortcuts.

The Discipline of Restraint

What I’ve come to appreciate is that both kinds of miscalibration usually stem from the same root cause: discomfort with uncertainty. Overwork is often an anxiety response. If I just do more, surely that will guarantee success. Cutting corners is also an anxiety response: if I just declare this done, I don’t have to sit with the discomfort of ongoing effort. Neither actually addresses the uncertainty; they just provide the illusion of control.

The mature approach is to tolerate the uncertainty while making your best assessment of what’s actually required. This means sometimes watching a problem unfold without intervening, trusting that it will resolve without you. It means sometimes committing fully to something exhausting because you’ve accurately judged that this is one of the moments that demands it. And it means being willing to revisit your calibration when new information suggests you got it wrong. The goal isn’t to always be right about how much effort something needs — that’s impossible. The goal is to have a clear-eyed process for making the assessment and the flexibility to adjust.

Don’t make things more difficult or take longer than they have to. But don’t convince yourself that difficult things are easy just because you wish they were. The leaders I respect most have developed this calibration over time, and they apply their energy with intention rather than habit. They know when to push and when to wait, when to dive deep and when to delegate, when the minimum necessary is everything and when it’s nothing at all.


This is not laziness dressed up as wisdom; it’s the recognition that your capacity is finite and the demands on it are not, so spending that capacity wisely is itself a form of excellence.

Posted on

Never make the same mistake twice

One of my most important principles is to strive to never make the same mistake twice. We all make mistakes, and though it’s important to be accepting and understanding of these failures in ourselves and our team members, it’s equally important to extract as much educational value as possible from mistakes in order to improve. A goal and commitment of never making the same mistake twice is guide that can help us to extra maximum value from these learning experiences.

“Never make the same mistake twice” is a mantra that resonates with most people, because most people recognize that making the same mistake repeatedly is detrimental to personal growth and development. Every mistake we make is an opportunity for growth and self-improvement, as long as we take the time to reflect on what went wrong and how we can avoid making the same mistake in the future. By consistently learning from our mistakes, we can make steady progress towards our goals and become more efficient and effective in everything we do.

Another benefit of avoiding the repetition of mistakes is that it helps to build our credibility and trust with others. When we make the same mistake over and over again, it can cause others to question our ability and judgment. On the other hand, when we take the time to learn from our mistakes and make an effort to avoid repeating them, we demonstrate to others that we are reliable and trustworthy. This can be especially important in professional settings, where our reputation and credibility can significantly impact our success.

For these reasons, the principle of never repeating the same mistake has broad implications on a larger journey toward success and improvement, and can be a guiding light that leads to patience, a better work ethic, increase objectivity, humility, and open mindedness.