Back in the era of the generalist
For most of my career, the advice has been to specialise.
Choose a discipline. Become excellent at it. Build a career around the depth of expertise that other people do not have.
That advice made sense. Most organisations were built around specialists because most worthwhile work required specialist tools and knowledge. A software developer wrote the code. A designer designed the interface. A researcher spoke to users. A product manager decided what should be built and tried to keep the whole thing moving in roughly the same direction.
One person could have a view across all of it, sure, but they could not do all of it well enough to produce a serious result.
Now though, I think it’s different.
We are back in an era in which someone with a broad set of skills, good judgement and an ability to learn can have an extraordinary ability to just get shit done.
Not because expertise no longer matters. Not because one person should replace an entire team. But because AI has dramatically increased how far one capable person can follow a problem before they need to hand it to someone else.
Following the problem
The most useful generalists are not simply people who can do a bit of everything. They are people who can stay with a problem.
They can work out what is actually happening, rather than accepting the first description they are given. They can speak to the people affected, examine the evidence, understand the constraints and explore more than one possible answer. They can make something, put it in front of people, learn where they are wrong and improve it.
Until recently, that journey usually crossed too many professional boundaries for one person.
Understanding a problem might require user research and data analysis. Exploring it might require service design or technical investigation. Testing an answer might require interface design, software development, copywriting and some kind of operational process. Even a relatively simple prototype could involve a small team, a collection of handovers and several different queues of work.
Now, someone who is strong in one of those areas can become capable enough in the others to carry an idea much further.
A product manager can interrogate a dataset, build a working prototype and put it in front of customers. A designer can connect an interface to real data and test the interaction rather than presenting a static mock-up. An engineer can analyse customer conversations, explore the wider service and test whether the thing they can build is the thing anyone needs.
The output will not always be production-ready, and I’m not sure that it should be expected to be. The important change is that one person can now get far enough to at least learn something real.
From specialist to product person
I studied software engineering and started my career as a software developer. Over time I moved towards product management.
That move was treated as a change of discipline. I stopped being a developer and became a product manager. The skills I had learned as an engineer were useful, but the organisational model encouraged me to work through an engineering team rather than continue building things myself.
There were good reasons for that. The software became more complex. The consequences of getting it wrong became greater. Doing both jobs properly was difficult, and half-doing either one was not useful.
But I can now do enough of both again.
I can explore a problem, research unfamiliar areas, work with data, design a service, build a prototype and test it with real people. I can use specialist tools without spending years becoming a specialist in each of them. Where I lack knowledge, I can get much further before needing help—and ask much better questions when I do.
That does not make me the best designer, engineer, researcher or analyst in the room. It makes me capable of getting to the point where we know which room we need, who should be in it and what they should work on.
That is a different kind of leverage.
Generalism is not vibe coding
The shallow version of this argument is that AI makes everyone an expert. It does not.
Generating some code does not make someone a software engineer. Producing a plausible interface does not make them a designer. Summarising a set of interviews does not mean they understand the people they are trying to serve.
AI makes it easier to produce convincing rubbish as well as good work. Without judgement, a generalist can move very quickly in the wrong direction.
The useful skill is not knowing a little about lots of things. It is knowing how the different parts of a problem fit together, where your own understanding is weak and when the work requires genuine depth. It is being able to distinguish a shortcut that helps you learn from one that quietly creates risk for somebody else.
The best generalists will still depend heavily on specialists. They will bring in an experienced engineer before a prototype becomes critical infrastructure. They will involve a researcher when the people affected are difficult to reach or the conclusions carry real consequences. They will know that legal, clinical, security and policy expertise cannot be approximated by a confident conversation with a language model.
AI does not remove the need for expertise. It changes when it is needed and makes it easier to use precisely.
Instead of assembling a full team around an untested assumption, a generalist can do enough work to expose the parts that are genuinely difficult. Specialist time can then be spent on the questions that deserve it.
Organisations built around outcomes
This should change how teams are formed.
The default response to a new idea has often been to identify all the disciplines it might require, estimate the capacity needed from each and put the work into their respective queues. That is expensive, so organisations understandably reserve it for ideas that already appear fairly certain.
The result is a familiar trap: an idea needs evidence before it can earn a team, but it needs a team before anyone can produce the evidence.
A capable generalist can break that loop.
Give one person a meaningful problem, access to the people who understand it and the tools to investigate it. Let them produce the first useful account of what is happening. Let them test the cheapest version of an intervention. Then form the team around what the work reveals, rather than around the assumptions made at the beginning.
This is not a case for running organisations as collections of heroic individuals. Important work still needs teams, institutions and durable expertise. It is a case for recognising that the smallest useful unit of progress has changed.
One person can now create enough momentum to make a problem legible, testable and worth organising around.
A return, but not a reversal
There is nothing particularly new about the generalist. Anyone building something from nothing have always had to move between disciplines. Early-stage founders do not get to declare that customer research, finance or operations sit outside their role. People doing difficult work in small organisations have always learned whatever the problem demanded.
What is new is the quality and range of work that one person can now produce, and how much more accessible this ability is.
The generalist is no longer limited to coordinating specialists or producing a rough approximation while waiting for the real team to arrive. With good tools, good judgement and selective specialist help, they can investigate, build and test to a standard that creates genuine evidence.
We were told to specialise because specialisation was how ambitious work got done. That will remain true for many parts of the work.
But the ability to cross boundaries, learn quickly and hold the whole problem in view is becoming valuable again. As execution gets cheaper, the scarce capability is increasingly knowing what deserves to be done, seeing how its parts connect and staying with it long enough to make progress.
The age of the specialist is not over.
But we are definitely back in the era of the generalist.