We've all heard from an engineering leader about the exact moment they realized their architecture had gotten too complex. It usually happens when they look at a service map and realize it looks like a box of tangled Christmas lights. This cognitive overload is exactly what Steve Evans, the former SVP of engineering at Chegg, reflected on in a recent post on LinkedIn. He argued that microservices were a trillion dollar mistake because we often over-build for future problems that never actually arrive.
During his eight years at Chegg, Steve’s team made it drop-dead simple for developers to stand up new microservices. While the goal was to ship faster, removing that friction created an incentive model that eventually backfired. As Steve and our co-founder and CTO Ganesh Datta explored on the Braintrust podcast, the choice for a developer's too easy when the cost of a new service is virtually zero. They can either dig into a complex existing service or spin up a new one to show progress in tomorrow's standup.
Most people choose the new service to show immediate results. While this makes sense for a single sprint, it's the start of a massive organizational tax that eventually outweighs the original benefits of microservices. To fix it, we have to look beyond raw velocity and start accounting for the long-term cost of every new box we add to the map.
Managing the organizational tax of architectural sprawl
We often talk about the benefits of microservices in terms of scaling and speed, but there's a macro tax that many organizations rarely account for until it's too late. We've seen how moving faster isn't always better when it leads to architectural sprawl that prioritizes the ease of getting started over the long-term reality of maintenance. Steve saw this friction first-hand during critical incidents where the sheer complexity of the system made it nearly impossible for the team to find their bearings.
"Someone pulls up the service map in your observability platform and it makes the New York City subway system seem simple. You are sitting there unwinding the Christmas tree lights and trying to figure out how this thing works. That is when you really start to see the cost." Steve Evans — Former SVP of Engineering, Chegg
When a service map reaches that level of complexity, incidents turn into a game of unwinding those lights in the dark. It can take an hour just to identify which service's talking to which other service. This creates a cognitive tax that every developer pays not just during an outage, but every day they open their IDE. It makes onboarding new engineers more toilsome and makes working across teams feel impossible. Eventually, the complexity of the architecture becomes greater than the complexity of the actual business.
Why technical metrics must tie back to business outcomes
The aforementioned cognitive tax is just one of many ways engineering leaders are rethinking how they measure productivity. Steve says that many leaders fixate on things like DORA metrics, cycle times, and release frequencies. While these are part of redefining developer productivity, they don't tell you if the team's heading in the right direction.
"We've spent a long time measuring how fast engineers run on a treadmill instead of looking at how far they're actually going. This isn't IT summer camp. We're not here for kicks and giggles. We're here to produce business outcomes." Steve Evans — Former SVP of Engineering, Chegg
It's worth looking at how these technical metrics actually map to the outcomes the business cares about. For a commerce team, that might be payment success rates, while for a healthcare provider, it's the accuracy of results. Measuring both inputs and outputs is the only way to ensure we're not just getting great gas mileage while heading in the wrong direction.
Ensuring context reaches the individual developer
One of the biggest challenges in any growing organization is the game of telephone that happens between the CEO and the individual contributor. By the time a strategic goal moves through VPs, directors, and managers, the context's often lost. This puts the developer at the end of the chain in a precarious position where they have to focus on closing tickets instead of thinking about how the business context has shifted.
"When you hire a junior engineer straight out of college, they think their job is to write code. When the CEO gets up in an all hands and talks about closing a big deal, it's usually in one ear and out the other. It's not important to them and it doesn't help them deliver their sprint." Steve Evans — Former SVP of Engineering, Chegg
Steve found that the best way to break this cycle is through small roundtables instead of large all-hands meetings. He says he brought together mixed groups of ten to twenty people from different functions to talk about what they were seeing in the ecosystem. This allowed him to spot where the context was getting blocked. Maintaining engineering excellence in the age of AI requires this kind of direct communication to ensure everyone's on the same page about the business context.
Maybe the real takeaway is that we've made our architectural decisions a little too frictionless. A bit of intentional friction might be exactly what's needed to make sure we're actually building for the business.
To listen to Steve and Ganesh's full conversation, check out the Braintrust podcast. While you're at it, book a demo to see how Cortex helps you align your engineering goals with actual business outcomes.
