There’s no shortage of prominent people talking about how the shape of software teams is changing. Middle management is getting thinner and more technical. Managers are getting back on the tools. Product and design folks are building things themselves. And engineers are increasingly expected to own more of the lifecycle (usually implicitly), rather than one well-defended slice of the codebase.

Reading these takes gives me déjà vu. A role where you meet the customers, design the thing, build it, ship it, and get paged when it falls over. That used to just be called software engineering.

Thoughts on generalisation from a professional toilet-roll holder installer

Anyone who’s worked in a small company (or for themselves) knows how valuable it is to be a generalist. I’ve built infrastructure, committed product PRs, fixed a toilet-roll holder in the office, and mounted a TV in a meeting room. The toilet-roll holder probably outlasted most of the software I built. 😆

Jokes aside, at Timely we used to regularly go to salons to meet our customers and watch them use the product. We’d then go back to the office and refine user stories, design the architecture, build, test, help with the GTM plan, then deploy, monitor, respond to alerts: the full end-to-end SDLC.

This happened in several companies I worked at, so I’ve worn some combination of these hats over the years: product owner, a (bad) designer, a front-end dev, a devops engineer, a DBA, a CISO, and a helpdesk technician.

Most people though, just based on the numbers, work in larger companies where specialisation is the norm. “You’re a React FE Engineer, you’re an Inference ML Engineer, you’re an Enterprise Product Manager.” The industry also just feels like it moved towards specialisation. I don’t know why, or whether it’s a good or bad thing, and that’s a rabbit hole I’m going to resist going down now.

AI democratised the stack

Jump to today, and your PM can vibe-code entire solutions. Your FE engineer is opening PRs against the Java backend. Your ML engineer is now a pretty capable data engineer. The tools have broken down the walls between specialisations.

Yeah, I’m glossing over some nuance here - these folks don’t have deep knowledge in their newly-acquired domains, and for some work that could come back to bite you. But it doesn’t stop them being “capable enough” to contribute.

The specialisation trap

I started chewing on all of this after watching Annie Vella’s talk on what she calls The Specialisation Trap. Her research found that the engineers thriving with AI are the ones with high self-efficacy - the “I’ve figured out hard things before, so I’ll probably figure this out too” muscle - and that you build that muscle through breadth of experience. The quote that stuck with me was “AI is an amplifier… what it can’t do is amplify what’s not there.” If your role has been narrowed down to the one task AI happens to be best at automating, there’s not much left to amplify, and it starts to feel like a threat rather than a superpower.

Go watch the talk. I’m not going to summarise it properly here, and it’s worth your time.

But what about the bosses?

Annie closes with a question that I’ve been mulling over: if the leaders who designed our atomised system of work were themselves atomised, can they design something better?

Think about your own org for a second. If your manager has only ever worked as a C# backend engineer - a decade of deep, narrow work - are they best placed to empower a team that’s suddenly working in this AI-assisted-generalist way? Empowering people requires being able to imagine what’s possible, and imagination is at least in part based on experience.

I want to be sensitive here, because if that’s you, it’s not a character flaw or a criticism. As a wise man once said “don’t hate the player, hate the game”, and the game for the past decade or two has rewarded specialisation. It’s also a game I’ve played, as I’ve gradually become more specialised over the years.

So what to do about it?

Nothing here is revolutionary. Companies have been sending senior leaders to work the phones in their call centres for decades, precisely because front-line exposure changes how you lead. I reckon we take that idea and stretch it across the whole software lifecycle, and across all roles/levels.

If you’re an engineer: find ways to gain exposure to new domains. Sit in on customer calls. Write the user stories. Put your hand up for the deployment, and the on-call roster. Some of it will be shitty, which is the point. What’s cool is that AI has made all of this far cheaper than it used to be. Becoming “capable enough” in an adjacent domain used to take years, but now you can often be productive on a task in an unfamiliar domain within hours.

If you’re a leader: all of the above, plus get back on the tools. Not to review your team’s code line-by-line (please don’t), but to rebuild your intuition for what’s now possible. It’s very hard to design roles around capabilities you’ve never touched.

Something this makes me wonder: does this set smaller companies up for success? Do generalists just “get” this new way of working faster than hyper-specialised folks? Is this why some metrics show junior developers adopt AI more effectively (because they haven’t yet specialised)?

I like the idea of more technical management and PMs shipping prototypes. Maybe it’s the industry gradually self-correcting back towards valuing breadth. Or maybe I’m jaded enough to wish I only had to worry about fixing toilet-roll holders and mounting TVs to walls. As always keen to hear your thoughts and experiences.

Cheers,
Dave