Skills that outlive their tools

I can spend a whole evening learning a tool and finish feeling more capable. Then a new version arrives, the interface changes and part of the evening needs doing again.

Some of that is normal. I build with software. Learning the tools is part of the work, and a better tool can make a real difference. But I started wanting a way to distinguish knowledge that travels with me from knowledge that lives inside this week’s interface.

I wrote down three questions.

Was the underlying skill useful a hundred years ago, and can I imagine it being useful a hundred years from now? Can I take it into a different industry? Does it require judgement when the answer is unclear?

Those are filters, rather than predictions. I can’t certify that a skill will survive a century. I can notice that explaining an idea clearly has a longer useful history than knowing where a particular app keeps its settings.

The same applies across my own work. Coaching and building websites look different. Both involve listening to someone describe a problem, working out what they actually need and explaining why the next step makes sense. The tools change. Getting that conversation wrong remains expensive.

That led me to a rough allocation: 60 per cent timeless fundamentals, 30 per cent transferable systems, 10 per cent current tools.

The fundamentals are writing, speaking, thinking and relationships. The systems are ways of solving problems that I can use more than once: breaking down an unclear goal, testing an assumption, reviewing work, building a repeatable process. The last part is the software I’m using to do it today.

I don’t track those percentages with a stopwatch. They’re a correction to my appetite. Left alone, I’m quite capable of spending most of my time in the last ten per cent, because that’s where the new things are.

There’s a danger in taking the rule too seriously. You can call something a timeless fundamental and use that as permission to stay vague. A person who reads about clear thinking forever without building or explaining anything hasn’t escaped the trap. They’ve found a quieter version of it.

So I want the layers working together. Learn a tool for a real job. Use the job to improve a transferable process. Pay attention to the human skill underneath it. A website becomes practice at understanding what a business needs. A coaching session becomes practice at giving an instruction someone can actually use.

That’s more useful to me than arguing whether specialists or generalists win. I need enough depth to do good work and enough range to carry what I learn into the next problem. Being interested in everything doesn’t excuse being useful at nothing.

The question at the end of a week is what remains if I change the software. Did I get better at explaining, deciding, testing or noticing? Or did I mostly get quicker at an interface?

Both can help on Monday. I want most of my learning to come with me when Monday looks different.