Back in the era of the generalist - Ed Parry

Back in the era of the generalist<br>For most of my career, the advice has been to specialise.<br>Choose a discipline. Become excellent at it. Build a career around the depth of expertise that other people do not have.<br>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.<br>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.<br>Now though, I think it’s different.<br>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.<br>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.<br>Following the problem<br>The most useful generalists are not simply people who can do a bit of everything. They are people who can stay with a problem.<br>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.<br>Until recently, that journey usually crossed too many professional boundaries for one person.<br>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.<br>Now, someone who is strong in one of those areas can become capable enough in the others to carry an idea much further.<br>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.<br>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.<br>From specialist to product person<br>I studied software engineering and started my career as a software developer. Over time I moved towards product management.<br>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.<br>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.<br>But I can now do enough of both again.<br>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.<br>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.<br>That is a different kind of leverage.<br>Generalism is not vibe coding<br>The shallow version of this argument is that AI makes everyone an expert. It does not.<br>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.<br>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.<br>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.<br>The best generalists will still depend heavily on specialists. They will bring in an...