The skills AI can't replace and how to build them
Communication, decisions, focus, questions, strategy. These don't expire.
🧠 Career Navigation · For developers navigating the AI era.
This week’s challenge: pick one skill from this edition and notice once today where you used it on autopilot. That’s where the practice starts.
A few months ago, a junior developer sent me a message I’ve received in different forms at least a dozen times since.
“I’m learning X and Y and studying Z. Am I wasting my time? Will any of this matter in two years?”
I didn’t answer right away. I wanted to give him the right one, not the fast one.
The truth is, I’ve interviewed hundreds of developers over the years. The ones I remember, the ones I hired and kept, were almost never the ones with the most tools in their stack. They were the ones who, when I gave them a problem with no clear answer, could slow down, ask the right question, and find a direction.
That’s a skill. It doesn’t expire. It doesn’t get deprecated. And most developers are so busy learning the next framework that they never build it.
So here’s my answer, for him and for you.
The skills that will matter in 2 years
If you ask me what made the most difference in my career across twenty years of building software, the honest answer tends to surprise people: communication.
Not the technical stack I mastered early. Not the architecture patterns I learned the hard way. Communication: the ability to express ideas clearly, understand what others actually mean, and move information between people without losing its meaning in transit.
The reason this surprises people is the same reason most developers spend years underestimating it: we assume we already have it. We’ve been communicating since we were children. We can write an email. We can explain what we’re working on in a standup. How hard can it be?
That assumption is expensive, and I held it myself for longer than I’d like to admit.
Communication is a practice, not a threshold you cross once. It degrades when you stop paying attention to it and compounds slowly when you do. Reading a book about it changes nothing unless you apply it consciously: in every message, every question, every meeting, every pull request comment. And it covers far more ground than speaking: it’s how you write a Slack message at 11pm when context is missing and someone needs to act on it, how you structure a document that people actually read instead of skim, how you ask a question that opens a conversation instead of shutting one down.
Most developers operate on autopilot across all of this. That’s where the gap lives, and where the biggest opportunity is hiding.
Two categories, two different futures
Everything a developer needs to grow falls into two categories with very different trajectories.
The first is technical skills: languages, frameworks, tools, platforms. These have always evolved, but AI is compressing the cycle dramatically. A specialization that would have stayed relevant for a decade now has a shorter shelf life. This doesn’t mean abandoning technical depth. It means being strategic about where you invest it. The durable bet in this category is foundations: system design, data structures, how distributed systems fail, how databases actually work under the hood. These don’t go out of fashion because every new tool is built on top of them. A developer who understands why a system degrades under load will adapt to any new infrastructure faster than someone who only knows how to configure the current one.
The second category is mental skills: the cognitive habits that make you better at any technical challenge, regardless of what the tools look like. Communication is one of them. The others are: how you make decisions, how you structure your thinking, how you protect your focus, how you ask questions, and how you think strategically. These don’t expire. They don’t get deprecated. Every year you invest in them, they compound. And with AI handling more of the execution layer, they become the primary differentiator between developers who thrive and those who plateau.
The rest of this edition is about those five.
How to make decisions
Making decisions seems straightforward until you realize what they actually cost. Every decision you make today removes options you could have had tomorrow. That invisible cost is what I call the marginal cost of decisions. Most developers never account for it.
Start by separating decisions by stakes. Some decisions have no real downside if you get them wrong: you can reverse them cheaply, learn quickly, and move on. For those, speed is the right optimization. But low and high-stakes decisions, the ones where you will lose something if you choose poorly, deserve a different kind of thinking.
For those, I use a structured approach: map the pros and cons explicitly, then spend time specifically on the cons. For each one, ask whether it can be diminished or removed through a different implementation, a phased rollout, a fallback mechanism, or a different sequencing of the work. The goal isn’t to eliminate cons, which is rarely possible, but to understand whether the pros genuinely outweigh them once you’ve accounted for the side effects.
This matters especially in product development, where decisions are rarely isolated. A feature decision affects architecture. An architecture decision affects hiring. A hiring decision affects what you can build next quarter. One choice can quietly close off an entire direction before you realize it’s gone. The developers who build lasting products aren’t the fastest decision-makers. They’re the ones who understand the downstream consequences before committing.
Without this kind of thinking, you’re not really deciding. You’re reacting. And the compounding costs of reactive decisions show up six months later as technical debt, misaligned product direction, and options you no longer have.
How to structure your thinking
A complex problem that stays in your head as a tangle of intuitions is still a complex problem. The act of structuring, deciding what’s the main point, what depends on what, what’s a cause and what’s a consequence, does something that pure mental effort can’t: it forces clarity.
The mechanism is simple but requires discipline. Before starting any non-trivial piece of work, write down three things: what problem this solves, what your approach is, and what could go wrong. Not as a formal document, but as a thinking exercise. The writing isn’t the deliverable. The clarity you arrive at before writing the first line of code is.
From there, practice hierarchy. Every idea has a level: there are top-level conclusions, the arguments that support them, and the evidence or examples that support those arguments. When your thinking feels tangled, ask yourself: am I confusing a conclusion with an argument? Am I treating an example as if it were a principle? Most mental confusion comes from mixing levels: treating a symptom as a cause, or a specific case as a general rule. Learning to separate them is a skill you build by doing it slowly and deliberately until it becomes instinctive.
This transfers everywhere: technical proposals, feature breakdowns, conversations where you need to bring someone else to your point of view. It also determines the quality of what you can build with AI. A developer who gives a well-structured brief will get dramatically better output, not because they’re better at prompting, but because they’ve already done the hard thinking before they typed a single word.
How to focus and go deep
The industry we’ve built rewards responsiveness. Slack notifications, standups, context switches, urgent messages. The average developer barely reaches genuine depth of focus before something pulls them back to the surface.
Deep work, the kind where you hold a complex problem in your head long enough to actually understand it, is becoming rarer exactly as it becomes more valuable. The shallow problems are being handled by automation. The ones worth solving require sustained attention.
The how starts with protection, not willpower. Block time in your calendar before the day fills with other people’s priorities. Communicate clearly when you’re unavailable. Treat a broken focus block the same way you’d treat a broken deployment: as something that needs a fix, not an inevitability.
But protection is only the first step. The deeper practice is building tolerance for the discomfort that comes at the start of deep work: the resistance, the urge to check something, the feeling that you should be responding somewhere. That discomfort is not a signal that something is wrong. It’s the threshold between surface-level thinking and the depth where real understanding lives. The practice is learning to recognize it as a threshold rather than an obstacle, and crossing it anyway. Repeatedly. Until crossing it becomes easier than avoiding it.
How to ask the right questions
A well-formed question is one of the most underrated skills in software development. But the goal isn’t to memorize a list of good questions, but to develop the capacity to generate the right question for any situation you haven’t seen before.
The mechanism behind a good question is always the same: you identify what’s being assumed and hasn’t been examined. Before asking anything, ask yourself: what does everyone in this conversation seem to take for granted? What would have to be false for this plan to fail? What are we not talking about that we should be? Those internal checks are the raw material. The question you ask out loud is just the output.
Years ago, I was in a meeting with an investor. He opened his notebook and showed me a single line he had written: “What haven’t we tried that we should try?”
That moment confused me at the time. I wasn’t prepared to understand what was happening. But what that investor was doing wasn’t asking a question. He was sharing a mental posture. A way of entering a situation with a deliberate blind spot detector. That question doesn’t ask for solutions. It asks for the shape of the unexplored space. It assumes that somewhere in the room there’s an untested path, and it creates the conditions for someone to name it.
That’s the quality a good question has. It doesn’t just request an answer. It shifts the frame of the conversation. And you can build that capacity by starting with one habit: before accepting any situation as fixed, ask what’s being treated as impossible that might not be.
How to think strategically
Most developers think at the level of the task. The best ones also think at the level of the system, the larger context in which the task exists, and the direction that context is moving.
The how is a practice of deliberate elevation. When you receive a task or face a decision, take thirty seconds to ask: why does this exist, and what does it move toward? Then go one level higher: what does the team or product need to be true in three months, and does this task contribute to that, or just to completion?
The second habit is consequence mapping. Before committing to any significant piece of work, ask: who else is affected by this decision that hasn’t been considered yet? What does this close off that we might want later? Strategic mistakes rarely feel like mistakes at the time. They feel like the obvious next step. The discipline is to pause long enough to look for what you can’t see from inside the immediate problem.
Over time, these two habits, elevating the question and mapping the consequences, become a mental reflex. You stop seeing tasks as isolated units and start seeing them as moves in a longer game. That shift is what separates developers who build things that matter from developers who build things that ship.
Where to start
These skills don’t come with completion certificates. There’s no course that teaches you to ask better questions. They develop through deliberate attention: noticing how you communicate, examining the decisions you make, protecting your focus, and treating every interaction as something worth doing consciously.
The reassuring part is that you already have the foundation. Every developer who has shipped real software, navigated team dynamics, and worked through real ambiguity has been exercising these skills, whether deliberately or not. The shift is simply to make the practice conscious.
That’s where the compounding begins.
Try This
If you’ve been following the previous editions and doing the exercises, you already have two artifacts: a map of tasks you’d delegate to five versions of yourself (Edition #1), and a breakdown of one of those tasks into judgment versus execution (Edition #2). Edition #3 asked you to identify one real problem in your work that no one is solving and write a single sentence describing it.
This week, take that problem and run it through the decision framework from this edition. Map the pros and cons of the most obvious solution. Spend twice as long on the cons as on the pros. For each con, ask whether it can be diminished, removed, or sequenced differently. Then ask: what am I assuming here that I haven’t examined?
These aren’t isolated exercises. Every artifact you’ve built across these editions is a compounding asset: a map of how you work, where your leverage is, and what you’re building toward. The goal was never practice for its own sake. It’s a system you’re assembling, one piece at a time, that will keep working for you long after you build it.
If this is your first edition, I’d encourage you to go back and do the Try This from editions #1, #2, and #3 before continuing. The exercises build on each other deliberately. Each one produces something you’ll use in the next. Starting here without that foundation means starting without the map. And the map is the point.
We’re scaling ourselves. That only compounds if the work accumulates.
The Deeper Cut
I’ve mentioned this before, but it’s worth saying clearly: I’m doing exactly what I’m asking you to do in the Try This sections. This is what walk the talk looks like.
From Edition #1, I analyzed my work week to understand where I could scale myself. The exercise produced a concrete list: over 3 hours a day reading and responding to messages from customers and colleagues, 2 hours on code review, 3 hours coding, 1 hour on architecture, and 2 hours creating content. Just writing it down made one thing obvious: the messaging block wasn’t just the biggest time sink. It was draining the energy I needed for everything else on the list.
From Edition #2, I picked that problem and broke it down into judgment versus execution. Most of the 3 hours was execution: retrieving context, piecing together what had already been said, figuring out who was asking and why. That breakdown made the target clear, and I built the Slack context retrieval agent directly from it.
From Edition #3, while working on the agent, I realized that identifying the gaps required recovering every decision and discussion that had shaped the build. Without that context, I couldn’t give AI a clear enough brief to help me think through the problems. That need produced the process log: a structured way to capture what was built, what was decided, and what actually happened. The process log then made the gaps visible, which led to the architecture decision: breaking the monolith into independent, composable agents.
Each edition produced an asset. Each asset made the next decision clearer.
The delegation map template, the format I used to produce the Edition #1 list, is available to all subscribers. Use it to map your own week. Run it regularly as your work changes.
Paid subscribers get the decision framework: the structured method for low and high-stakes decisions covered in this edition. The tool that turns the thinking in this edition into a practice you can apply to the next real decision you face.
The map shows you where your leverage is. The framework helps you move toward it without closing off the options you’ll need later.