Everyone talks about how “change is hard” in software. We dread migrations, refactors, and rewrites. But let’s be honest: software is built to change. That’s literally in the name. What’s brittle isn’t the code, it’s the people and the structures around it. If your team can’t change direction without six meetings, your bottleneck isn’t technical. It’s cultural.

If you want to bask in all that software can provide, it’s time to ensure you’re not capping it with your wetware.

Conway’s Curse

To understand your org’s impact on the code itself, let’s start with Conway’s law. Code eventually mirrors the composition of the team that created it. If you have a frontend/backend split, the architecture will reflect that, unlike companies with cross-functional pods.

But that’s just the start. Structure ossifies flow when team boundaries are drawn by ego, politics, or history instead of logic. We encode dysfunction into the codebase. Teams spend more time negotiating ownership than creating impact. When we give people titles that split up the system, or spin up too many nano-teams, we keep piling burdens on the engineers and their creations. We design org charts like medieval fiefdoms, then wonder why our architecture looks like a border map. The mythical moat ends up being an internal one.

The Momentum Trap

Another issue is that people confuse activity with progress. PMs feel pressured to feed the beast—as if engineers will starve without Jira tickets. Roadmaps get driven by the need to look busy, not by actual impact.

Often, I see even young startups where feeding engineers becomes more important than generating insight. Whereas we’re used to thinking of startups as places where no one ever has time to do everything, the truth is more complex. When you actually get amazing engineers and not just claim to do that on LinkedIn, you often find that they aren’t the bottleneck.

That then makes good people worried about not having the engineers utilized at 100%, leading the organization to generate a lot of work. That abundance of features and edge cases that get prioritized for no good reason essentially results in accelerated aging of your codebase. Things become much harder to maintain, and the team never relents on piling on more and more features—even if those often go unused.

Organizational Calcification

Leaders glorify “stability” as maturity, when often it’s just stagnation in disguise. They freeze processes, roles, and responsibilities: the exact opposite of agility. They fear “rocking the boat” too much and thus avoid changing things up in the organization. Those changes you don’t make are precisely those that would’ve enabled your software to maintain agility.

You don’t get stability by staying still. You get it by learning to move without breaking. I know a VPE who didn’t want to stress the QA group. Even though they had a 1:3 ratio between QA engineers and software engineers, they were getting poor results. His fear of making any changes ended up with things reaching the point of no return: the entire QA department was sacked when the board had had it.

Similarly, rules, reviews, sign-offs, dependencies—all born with good intent—eventually form layers of organizational plaque. Nobody set out to make change impossible; they just kept adding safeguards until nothing could move. Every new process is a small tax on change. Over time, the bill comes due.

Breaking the Rigid Reflex

But you can counteract it. Redraw boundaries regularly, and create organizational structures that can change like organisms. Measure the throughput of your org by impact, not tickets or features accomplished. That will allow everyone to focus on choosing to do the right things, as opposed to having a mindset where each engineer-minute must be utilized for making keyboards clack.

Embrace the testing hack to regularly have experiments and changes as part of your culture. Reward those who simplify, not those who expose their brilliance with complex and clever solutions. Stretching is important as you age to maintain flexibility.