#55 The Return of the Generalist: Broader Skills and Smaller Teams
Two weeks ago I was back at Malmö University. Same advisory board, different conversation.
Last time I was there I talked about business acumen, understanding people, and ethics. The things that were true 30 years ago and are still true now. This time I wanted to talk about how something we interpret as new is making something old come back.
A one-person show
In the mid-nineties I was a one-person show. I'd meet a client, figure out what they were trying to achieve, interview their users, sketch domain models and conceptual designs on paper, and then implement the solution myself. Authorware. Director. Access. Dreamweaver. Visual design and development tools. I'd been programming as a kid, so I could edit code even if writing it from scratch wasn't really an option. I built everything from websites for minor organisations to a database visualizing non-destructive inductive testing of tubes at a nuclear power plant.
It was a lot. But design and development, and the tools at hand, were still simple enough for one individual to pull it off.
Twenty specialists
After a PhD student detour focusing on Air traffic control systems in Copenhagen I worked for two different consultancies before co-founding inUse. Complex solutions had always existed, but now they were everywhere. Teams started growing.
Fast forward twenty years and the "design" side alone had split into a dozen specialisms. Service designers, user researchers, ux designers, visual designers, frontend developers, content designers, information architects, UX copy specialists… I have nothing against UX copy. Good microcopy is essential. But when you need 20 specialists to ship something, you spend more time on administration and handovers than on actually making things.
We expanded our way into near paralysis. People invented frameworks like SAFe to manage the complexity, and wrote (great) books like Team Topologies just to figure out how to work together.
A contraction
Enter LLM-based services. I understand the PM or CEO who gets tired of waiting for design or engineering and just builds something in Lovable. It's frustrating to sit in a queue when there's a service in your browser that can produce something “working” in an afternoon.
In many ways it reminds me of when desktop publishing arrived. Arts & Letters. Corel Draw. Suddenly everyone could make a sign. And we still live with Comic Sans in shop windows and classrooms. We'll now have to live with the equivalent in software. Functional, ugly, but sometimes good enough.
I told the students and teachers that I think this contraction is healthy.
I know the objection. I’ve made it myself many times. Quality will suffer. PMs building products without research or design training is a disaster. And yes, sometimes it will be. But "good enough" is only a problem when good enough isn't actually good enough, and that depends entirely on what you're building.
When good enough isn't
Air traffic control systems need people who go genuinely deep into human cognition, error recovery, and situational awareness. So does any product competing on experience in a saturated market. No AI services covers that, and pretending otherwise is how you get people killed and lose customers.
"My Pages" in an enterprise system is a different matter. A capable person with good AI services, a solid grasp of the business, and at least some understanding of the users will do fine. The stakes are lower. The differentiation isn't there.
What separates these two situations isn't complexity. It's how directly the understanding of the users and the quality of the experience affects the outcome.
The cost of handovers
With the new set of services, teams can be smaller again. Fewer handovers, not because we've invented a better process, but because one person can cover more ground again.
The problem with the handovers was never that specialists existed. It was that each specialty created an interface. A document. A deliverable. A meeting. And at each of those handovers, time was wasted and understanding got lost. The researcher handed insights to the strategist. The strategist handed a brief to the interaction designer. The interaction designer handed specs to the visual designer. By the time something reached engineering, the original thinking about actual human beings in actual contexts had been abstracted almost beyond recognition.
Smaller teams with broader skills don't just move faster. They preserve understanding across the whole process. The person building the prototype also did the research. They remember what they saw when observing the user. They feel the tension between what was discovered and what's being built. That matters.
I don’t think that one person can replace an entire development team, but teams can certainly be smaller again. And that’s a good thing.
If you're starting out now
Not everyone benefits from this. I won't pretend otherwise. Designers with a too narrow profile are in a difficult position right now, and many need to widen their scope.
If you're just starting out, don't specialize too early. Go wide. Cursor, Claude Code, and Lovable will help you experiment and iterate faster. But speed only helps if you're solving the right problem. The skill that matters is identifying that problem, for the business, and for the people using the product. No LLM based service replaces that.
I said that at this same table a year ago. It's still true. Business, people, technology. Make sure you understand all three.
…
Afterwards, one of the teachers turned to me.
– We hear what you say, he told me, but the curriculum is already full. It's hard to add things.
– Show it to me, I said. I'll make room.
I meant it. They're doing great work. But I love to help if I can.