Good morning, picnickers. 

Over the past month, I’ve been writing on how design can carve a path through the great big mess of our industry. But that’s far from the only proposed model for moving forward. The new hotness is “democratizing design” that has manifested in tandem with a very old idea – that workers (not just designers, but PMs and devs as well) should become generalists. 

But as human knowledge has grown, we have increasingly become specialized. I’ve written previously on this effect in Product and Design and why it’s beneficial – a junior designer is more valuable to their team as an authority on design than they are as a backup product manager. 

Unfortunately, as we continue to specialize, our managers are increasingly bad at understanding what we actually do. This is a gap that can be bridged with trust, but in low-trust environments, the dynamic encourages a particular type of generalist – a harmful solutionist – to emerge and take over. 

Generalism as a survival strategy 

A lot of the pressure that pushes people to generalize is a failure mode of some sort or another. In a resource-constrained environment where key skillsets are missing, it can be the only way to get things done (with rapidly diminishing returns due to the time constraints of generalists).  

Are those generalists actually doing a good job? In a dysfunctional environment, it’s not the right question to ask. Where management is not facilitating a functional process, generalists are doing the only job. Genius autodidacts who can do the end-to-end process by themselves are the only people who can get anything done.  

The quality of the work is poor, of course. But it doesn’t matter if management can’t tell the difference. To understand quality you need to have a deep understanding of the problem, and the more specialized the skillset required to solve it, the worse you get at explaining to non-specialists. 

This leads to troubles when employees fail to execute seemingly simple requests like “make the product intuitive” or “do Agile.” The manager is baffled by the amount of work necessary; their team appears to be just sitting around and making excuses. Meanwhile the generalists – who are continuously delivering something – acquire a halo of competence far beyond their actual ability. It starts to feel like they can truly do everything. The myth of the almighty unicorn designer continues to grow. 

“Everyone is stupid except me,” and other fables for children

This is where the template ronin roll into town, armed with the twin swords of Powerpoint decks and Miro boards. They are not always consultants, but they are almost universally brought in from the outside. They are not experts in any field, but they carry the appearance of expertise across all areas, because they know just a little bit more than your manager does (as external hires the actual depth of their knowledge is not yet evident). 

The ronin are given a broad mandate because they carry a message so ingrained in our modes of thinking that no specialization is required to understand it: your people are stupid, but I will heroically solve their problems. They can confidently present the manager with a simple solution that feels intuitively right because they do not understand the problem either.

That simple and intuitive solution is almost universally the same: the team needs to stop everything they’re currently doing and adopt best practices (don’t think too hard about what “best” means, that’s not one of the best practices). This is particularly common with “agile transformations” and an entire industry of coaches has been training teams on the same Agile 101 material for twenty years. 

The state of the art hasn’t budged because best practices are not the problem. People are not stupid, and can look up their own thought leadership articles. If doing Agile (or design thinking, or product operating models, or whatever old thing is new again) was as simple as “read the manifesto and then do that” there would be no ongoing demand for Agile transformation. 

But template ronin are not interested in the hard work of figuring out what went wrong the last time we tried Agile transformation. All they’ve got is the templates. Using these tools for not-thinking they can rapidly skip over all the context and zero in on a thoughtless solution. Instead of identifying the real bottlenecks, the complexity is simply deferred until someone doing the actual work runs into them face-first. By which point, ideally, the ronin have moved on to the next contract or executive role, and the blame falls back on everyone else for not using the new awesome process correctly. 

AI is an enabler, not a solution 

The parameters of the template ronin’s favorite field of engagement – great marketing, short time horizons, shallow solutions – are the perfect fit for chatbot-powered tools. The tech is mid, but that’s not a problem when neither the ronin nor the target audience can’t tell good from bad. Ongoing use of AI is documented to make you stupider, but being smart was never the differentiating factor. AI can pretend to be smart for you. 

And if deferring complexity is the name of the game – it’s what tech solutionism is best at.

The other thing AI is really good at is executing linear tasks. Template ronin are among the few people whose jobs are actually at risk from AI, so they are rushing to adopt it in droves. Laggards are doomed; vibe-coded prototypes bring much more ✨magic✨ to stakeholder demos. 

Unfortunately, producing stakeholder demos is not a real job. The real job is solving problems, and those problems live in the incumbent systems. Design school may teach exclusively 0-to-1 projects, but very few real-world projects start by completely dumping the (hopefully) working and revenue-generating product. 

Solving problems in production rather than in theory requires changing what you deliver. To do that you have to understand your local context instead of an idealized blank canvas. You have to think in ecosystems instead of siloed users. 

Good Questions 

Template ronin are able to slip away from a job half-done solely due to an ill-defined definition of what “done” actually entails beyond “an output was produced.” The more an area of the work is democratized, the more difficult it will be to evaluate whether that output is actually fit for purpose, short of the slow and hard way (by deploying it). 

If you have the runway then by all means, go ahead. But heed Anupriy Kanti’s advice, and ask yourself this question early and often: 

The real “definition of done” for an Agile transformation is not “people are doing the methods.” The methods are the easy part. The hard part is tracking whether doing the methods has actually made you deliver more value, more quickly. Until that happened, the job isn’t actually done. 

The real “definition of done” for a software product isn’t a demo. It’s observing attributable change in your top-line indicators. If you don’t have that, your feature didn’t do anything.