Tiny teams move fast because nobody argues over job boundaries. One day you're tweaking CSS, the next you're writing a quick‑and‑dirty data migration. The product needs finishing, so hats get stacked and you run with it. Traditionally, as a team or organization grew, there came with it opportunities for individuals to specialize. However, as always, as headcount rises the magic thins: hand‑offs appear, swim lanes form, and the question of who owns what starts stealing cycles. That tension is today’s stop on our tour of scaling pains ... in addition to looking at how the industry keeps swinging between specialists and generalists as the landscape changes.
The Evolution
When I started in the tech industry (around y2k), larger dev teams looked like a deli counter: Dev, SDET, Release, Ops, UX, each with its own ticket queue. Depth and craft thrived; if a service coughed at 3 a.m. you knew exactly whose pager to ping. The flip side was a quiet erosion of accountability. I watched more than one feature ship with obvious bugs because the developer assumed “QA will catch it,” and I’ve seen poor SRE teams drowning in noisy alerts no one upstream felt responsible for. So the original phase shift of a small team growing into a larger team of specialists slowly began to change how it manifested.
Unit testing methodology exploded onto the scene, CI/CD gave way to DevOps, infrastructure definitions moved into IaC (Infrastructure as Code). All of these evolutions arrived ostensibly as a cure for the ills seen by many large teams ... while at the same time empowering smaller teams. However, as accountability for quality and uptime shifted left landing, these concerns increasingly began landing squarely on the individual developer’s desk. Front‑end frameworks matured and API tooling improved, blurring the line between “front end” and “back end.” Engineering teams started asking for full‑stack engineers; pure FE or BE roles have started feeling like a bit of an endangered species in some orgs. As I write this, AI seems to have only accelerated the trend, as LLMs write more and more code, PMs are increasingly being expected to start vibe coding PoCs, and engineers are being nudged to dabble in everything from product copy to incident response. On paper it’s efficient ... easily fungible "resources" that can be moved around as corporate priorites change faster than you can say "sprint!"; in practice it often feels like everyone just now has seven half‑jobs instead of one whole one.
So instead of allowing a smaller team to scale and have higher impact, what we're seeing is that focus evaporates when context switches pile up. Career ladders blur because mastery is hard to measure, and burnout climbs as people juggle roles they never trained for. The Game Industry has always been unfortunately well known for crunch time and burnout ... a trend we're definitely seeing gain momentum in the overall tech industry.
A Way Forward?
The original pendulum swing toward generalization fixed real problems; the industry just overshot in an ever-increasing effort to hyper-optimize productivity and reduce costs. Teams should treat specialization as something you borrow, rather than abandon as you grow. Spin up an SRE squad when reliability debt spikes, embed an accessibility guru when if you find yourself behind in that imporant endeavor, hire a security pro for a threat‑model boot camp as you design a new feature ... then fold those lessons into everyday practice and let the specialist step back (if they're a consultant it can signal the end of their contract, or if they're a team member you've asked to specialize they can mix back into the general population and refocus on other needs). If you notice recurring sev‑2s no one can untangle, quality regressions despite “full‑stack ownership,” or decision gridlock because nobody has deep enough context, that’s your cue that you should think about adding specialists for a time. Specialists are of course not free, however the ability to use them when needed, but maintain the flexibility of employing generalists will strike a good balance over time.
Healthy teams should keep the pendulum moving on purpose: generalize when speed matters, dive deep when (or before) cracks appear. Balance rarely lasts, but deliberate motion toward it keeps both the product and the people upright.