Skills That Multiply Each Other
Most engineers pick their next skill to learn based on what's trending, what a job posting mentioned, or whatever looks interesting on a conference schedule.
The result is a grab bag. A little Kubernetes here, some public speaking there, maybe a side project in a language you'll never use at work. Each skill on its own is fine. But they don't connect, so none of them change how you actually work.
I learned this early in my career. In college, I discovered I loved visual communication and design, enough that I worked with my school to build a curriculum around it.
When I started applying for jobs, that design knowledge, paired with my frontend development skills, made both more valuable. Because of my skill set, I made better design decisions while building interfaces, and I could translate design intent into code without a handoff gap.
That pairing wasn't an accident, but it took me a while to realize why it worked so well. The design skills gave me a lens that improved my development work. The development skills gave me a medium to actually apply the design thinking. Each one fed the other.
That feedback loop is what separates skill pairs that compound from skills that sit next to each other on a resume.
Random Skills Accumulate. Paired Skills Compound.
When you pick up a skill that has no connection to what you already do, you have to find or create a context to use it. That's a high bar, and in practice, it means a lot of learning that never gets applied.
Paired skills work differently. They lower the barrier to application because the context already exists in your daily work.
A 2023 analysis from Bruegel, a European policy research organization, studied how skill complementarity affects career outcomes. Their finding was clear: the value of any individual skill depends heavily on which other skills surround it. Skills that complement each other produce outsized returns. Skills that don't connect produce diminishing returns.
This maps directly to what I've seen in engineering teams. An API developer who learns data modeling doesn't just "know data modeling." They design better APIs because they understand how data flows through the systems they're building. The two skills reinforce each other constantly.
Compare that to the same developer picking up mobile development on the side. It's a useful skill in the abstract, but it's disconnected from their daily work. They rarely get to apply it, so it fades.
Scott Adams, the creator of Dilbert, popularized a similar idea, which he calls the talent stack. He argues that you don't need to be world-class at any single thing. You need to be good at a few things that fit well together. The combination becomes your edge.
The nuance for engineers is that "fit well together" isn't random. The best pairings are those in which practicing one skill naturally sharpens the other.
How to Find Your Next Pairing
When deciding what to learn next, the instinct is to ask, "What's in demand?" That question points you toward trending topics, not toward skills that will actually change how you work.
A better set of questions:
- What would make your strongest skill more effective? If you're a strong backend developer but you've never thought deeply about observability, your code ships into a black box. Adding monitoring and observability skills means you can verify that what you build actually works in production. Your existing strength gets more complete.
- Where does your work hand off to someone else, and what do they need from you? If you write APIs that frontend developers consume, learning some basic frontend thinking will change how you design those APIs. You'll anticipate what the consumer needs, rather than making them work around your design. I've written before about how building connected knowledge in adjacent areas helps you collaborate more effectively and see the broader system. This is the same principle applied to your learning strategy.
- What non-technical skill keeps limiting your technical impact? If your architecture proposals keep getting deprioritized, the issue probably isn't the architecture. It might be how you present the case for change, how you connect technical work to business outcomes, or how you build alignment before proposing. Those are learnable skills, and they pair directly with what you already know.
You don't need to answer all three. One honest answer is enough to point you toward a skill that will compound rather than collect dust.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
The Cost of Collecting Without Connecting
Spreading your learning across unrelated areas feels productive because you're always learning something. But when nothing connects, you end up with broad familiarity and shallow application. You know a little about a lot of things, and none of it reaches the depth where it changes how you approach your actual work.
This shows up in practical ways:
- Your resume lists skills you can't demonstrate. You learned enough to follow a tutorial but not enough to apply the skill under real constraints. In interviews and on the job, that gap is visible.
- Your learning time doesn't convert to impact. Hours spent picking up a new framework that you never use at work is time you could have spent deepening a skill that pairs with your daily responsibilities.
- You plateau without understanding why. You keep learning, but your effectiveness doesn't change. The issue isn't effort. It's that the new skills aren't reinforcing the ones that matter most.
This isn't an argument against breadth. Breadth matters. But breadth without any connective thread between the skills you're building means you're always starting from scratch instead of building on a foundation.
Start With What You Already Do Well
The next time you're thinking about what to learn, resist the pull of whatever's trending. Instead, look at the skill you already rely on most and ask a simpler question: what would make this one significantly better?
The answer almost always points toward a skill that pairs with your existing strengths rather than one that sits beside them. And that pairing, practiced over time, will do more for your career than any list of unrelated competencies ever could.
What you learn matters less than how what you learn connects to what you already know.