The "Tech Pendulum"
Swaying between extremes
Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.
Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.
We humans love to swing between extremes. This is a behavior we see in many aspects of our lives; fashion trends, political ideologies, and even our personal habits. The tech industry is no different.
There are many trends in our industry that swing back and forth over time. In this article, we will explore some of the most notable swings in the tech world, understand why they happen, and look at how we can turn them to our advantage.
The swings
We see many swings in the tech industry. In some cases, they go back and forth indefinitely between two extremes. In other cases, they evolve into new paradigms that build on the lessons of the previous cycle. Either way, these swings reflect our ongoing quest to find the best ways to build and deliver software.
Let’s explore some of the most prominent ones.
Pendulum Swings
Pendulum swings refer to the oscillation between two extremes in various aspects of software development and technology. They tend to happen when there are two legitimate approaches to solving a problem, and the industry swings between them over time as new challenges arise or as different voices advocate for one approach over the other.
Quality Assurance (QA) Engineers
Companies that are sufficiently large will often have Quality Assurance (QA) engineers. In some organizations, QAs are deeply integrated into the development teams, working closely with developers to ensure quality throughout the development process. This inevitably leads to a more collaborative approach to quality assurance, where the QA engineers develop alongside the developers and quality becomes a shared responsibility.
In other organizations, QAs operate as a separate entity. They will often have their own organization (eg. QA managers, QA leads, etc.) and will be responsible for the testing strategy and for ensuring quality independently from the development teams. This separation can lead to a more formalized and structured approach to quality assurance but may also create silos and communication gaps between development and QA teams.
As with anything, there are no right or wrong approaches.
There are no solutions. There are only trade-offs.
Designers: Embedded or Centralized
A similar swing happens with designers. Should designers be embedded within product teams, sitting next to engineers and product managers, sharing the same goals and rituals? Or should they live in a central design organization that guards consistency, owns the design system, and serves the rest of the company as an internal agency?
When designers are embedded, they develop deep product context and move quickly with their team. The risk is fragmentation: each team evolves its own patterns and the overall experience starts to feel stitched together.
When designers are centralized, consistency and craft tend to improve, and there’s a clear career path within the discipline. The risk is distance from the product: designers can end up as order-takers, delivering mockups that miss the nuance only daily exposure to the team’s problems can reveal.
Neither extreme is sustainable for long, which is why we keep seeing companies swing between the two.
On-Prem vs Cloud
For decades, running your own data center was simply how you ran software. Then the cloud arrived, and the industry swung hard: AWS, Azure, and GCP became the default, and “cloud-first” turned into “cloud-only” for many organizations.
Now the pendulum is moving again. Rising cloud bills, latency requirements, data sovereignty regulations, and the realization that not every workload benefits from elasticity have pushed companies toward hybrid setups, edge computing, and even outright repatriation back to their own hardware. The next generation of engineers will likely inherit a world where the question isn’t “cloud or on-prem” but “which workload belongs where”.
Specialized Roles, Full-Stack, and T-Shaped Engineers
The shape of the engineer has also swung over time. Early software organizations leaned heavily on specialists: database administrators, front-end developers, back-end developers, and operations engineers all living in separate boxes. Then the full-stack developer emerged, someone expected to handle everything from the database to the browser, often on small teams where specialization was a luxury.
Today, many organizations talk about T-shaped engineers: broad enough to collaborate across the stack, but with one area of genuine depth. This is arguably an evolution rather than a pure swing, but it’s driven by the same underlying tension: how much breadth versus depth do we want from any given person?
Progressive Evolution
Some swings don’t return to exactly where they started. Instead, each oscillation incorporates lessons from the previous one, and the industry settles into something new.
Architecture: Monoliths, Microservices, and Back Again
We started with monolithic applications, large single deployables that were easy to reason about but hard to scale organizationally. The industry then swung toward microservices, promising independent scalability, team autonomy, and polyglot freedom.
After years of living with distributed systems, many teams discovered that the operational and cognitive overhead of microservices was often larger than the problem they were trying to solve. The pendulum is now swinging back toward “modular monoliths” and “macroliths”, architectures that preserve clear module boundaries without the distributed-systems tax. We’re not back where we started; we’re somewhere new, armed with better tooling and a healthier respect for complexity.
Waterfall, Agile, and Post-Agile
Software delivery methodology has followed the same pattern. Structured waterfall gave way to the Agile revolution, with its sprints, stand-ups, and iterations. Now we see “post-agile” movements questioning the ceremony overhead, pushing for continuous delivery, smaller batch sizes, and less ritual for ritual’s sake. Again, we’re not going back to Gantt charts, but we are questioning which parts of Agile actually deliver value and which parts are just theater.
Why does the pendulum keep swinging?
With all the examples above, I’m certain you had an opinion on which side is better. For every person who believes in one extreme, there’s another who believes in the opposite. Since opinions tend to balance out around the 50% mark, the pendulum keeps swinging. Whenever there’s a slight imbalance favoring one extreme, the pendulum starts to move in that direction, and the louder voices pull everyone else along.
If one approach could be definitively proven better than the other, the pendulum would settle. However, most of the examples we’ve examined require years of execution to demonstrate their effectiveness. Since technology landscapes rarely remain stable for that long, these approaches are seldom proven definitively superior. Therefore, the pendulum continues its motion.
This is especially true in the software industry, which is relatively young and still exploring different approaches. The journey from monoliths to microservices and now back to modular monoliths exemplifies this ongoing exploration. We still don’t know what the optimal approach is. When we refactored our monoliths into microservices, we believed we had discovered the best solution. But after staying at that local maximum for several years and experiencing the challenges of maintaining such systems, we’re exploring alternatives once again.
What can you do about it?
Keep calm and carry on.
The worst thing you can do is jump on every swing as it happens. By the time a trend has enough momentum that you’re hearing about it at every conference, you’re already late, and the pendulum is probably already preparing to move in the opposite direction.
Instead, a few habits can help you stay grounded:
Be observant of the swings. Notice which direction your corner of the industry is moving and, more importantly, why.
Understand where you are in the swing. Are you near an extreme, or somewhere in the middle? The closer you are to an extreme, the more likely the next move is away from it.
Prepare yourself for the swing. If you see momentum building in one direction, think through what it means for your team, your architecture, and your career before you’re forced to react.
Build skills that are independent of the swing. If you invest all your energy in becoming the world’s leading expert on microservices, you’ll be in an awkward spot when the pendulum swings back to monoliths. Skills like systems thinking, writing, communication, debugging, and reasoning about trade-offs survive every swing.
Be honest about trade-offs. Every side of a pendulum swing optimizes for something and sacrifices something else. Name those trade-offs explicitly instead of pretending one side is just “better”.
Conclusion
The pendulum will keep swinging. It’s inevitable, because it’s human nature to over-correct, to chase novelty, and to believe that the latest idea is the final one.
Our job as engineers and engineering managers isn’t to stop the pendulum or to perfectly predict its next move. It’s to stay aware of the motion, to make deliberate choices about when to ride it and when to stand still, and to keep investing in the skills and judgment that stay valuable no matter which way it’s swinging.
Better to be ready for a swing that never comes than to be caught off guard by one that does.