Sophia has been with the company for over a decade. In that time, she grew in her role and established herself as one of the go-to people, eventually earning her staff title. In an emerging area, she realized many teams used different approaches, so she wanted to introduce a standard. Her colleagues liked her ideas and supported her initiative, and management agreed that she should implement a framework.
Projects started using her framework. For one project, engineers found that the framework didn’t really work the way they wanted. They found bugs, anti-patterns, and over-engineered abstractions. Three of them suggested changing the framework substantially because they felt it was causing friction in their own work. Sophia disagreed. One of the engineers, who’s relatively new to the company, reached out to leadership to explain the problem. Leadership ended up supporting Sophia. The existing framework prevailed without much of a change.
We can imagine Sophia is right, visionary, stubborn, incompetent, or egotistical. Perhaps. It depends on who is thinking about Sophia.
The Caryatids: When Questioning the Structure Means Questioning Her
The Credit Has One Name
Sophia has grown her expertise within the company. She learned ways of working, the domain, nitty-gritty details about some customers, and the systems that predated her. As Sophia becomes associated with the company's decisions, she becomes the person everyone points to. Sophia built X, Sophia architected Y, Sophia knows why we did it this way.
In essence, software carries years of decisions compressed into what we see today. It’s easy to recognize individual achievement because it has a name to represent it, although that achievement is supported by reviews, discussions, and guidance. When we give an expert all the credit, we give her the keys to the domain. She becomes the de facto gatekeeper of which changes move forward and which are turned away.
This is rather practical. We invest in people and trust them when they show competence. If the framework is hard to extend or adopt, the argument can become about Sophia's judgment. The company needs what Sophia knows. The trouble starts when it also needs to question something she built. Her framework does two jobs now. One, a measure of her own competence and architectural judgement. Two, a standard that helps the wider organization. Engineers need the second but they have to deal with the first sometimes.
More to Lose Than a Design
Interestingly enough, there are a few motivations here. You can enjoy deep learning in an area, show that you’re capable of solving problems in it, or work to avoid being seen as failing. All three can result in tremendous effort, but they don't necessarily produce the same response to constructive criticism. We don’t know Sophia’s motivation. Nevertheless, once her framework was accepted, questioning its limitations also put her credibility at stake.
When Sophia was building the framework, finding a mistake meant she could fix it, learn something, and move on. Now that people have accepted it, the same mistake might be seen as evidence that she made a bad architectural decision. She has spent years earning the company's trust, and people expect her to get these decisions right. Sophia might think this is all nonsense and have no problem changing the framework. Nevertheless, the cost of being wrong has changed. Something that previously helped her become a better engineer might now make people question her judgment.
Suppose three engineers show Sophia where her framework breaks and doesn’t allow extension without major hurdles. She remembers that she introduced the pattern because of abuse by a large customer. That might be a requirement the engineers may have missed because they weren't there to see what happened. Sophia might be the only person who remembers why the pattern exists.
On the flip side, what if the requirement has changed or moved to a different component? Then the pattern still taxes every project and no longer protects anything. An explanation for a decision we made a few years earlier might still be accurate without justifying it today. The original justification may no longer apply. If she stops questioning whether those constraints still apply, the business risks carrying technical debt as opposed to consistency.
An Objection Sounds Different From a Newcomer
Three engineers have been challenging the framework, but their colleagues have accepted it and have been using it for a while. There’s an additional challenge the newcomer faces. From other people's point of view, does the newcomer even know enough to suggest major changes or a rewrite to a framework?
Criticism lands differently based on who raises it. If it comes from an established team member, people may see it as care for the team. When it comes from a new joiner, it might sound dismissive of the people who built and used it. The difference emerges even before anyone actually looks at the arguments against the framework.
In these cases, escalation might be necessary because you want to correct the course. Nonetheless, this quickly becomes a question of authority over architecture. Sophia has more to defend than her design, and the newcomer needs to challenge more than just the framework.
The engineers who work closest to the framework have the most immediate information. Still, they might think filing another objection is pointless. Sophia might feel like her framework, and the judgment behind it, have been accepted. Leadership might feel that an experienced engineer has prevented a risky rewrite. The trouble is that the organization risks losing its ability to evaluate the framework independently.
Test the Design, Not the Person Behind It
Reopening the same argument can open another can of worms, so people usually avoid it. The trouble is that leadership has already settled the debate, but we still don't know how much of the problem comes from the framework. How difficult is it to extend? How often do changes introduce defects? And how much of that trouble comes from the foundation itself? We never answered any of these, yet somehow we settled the debate.
Let's start with the basics. When a project uses the framework, where does it create friction? Which defects come from the framework, and which come from the project's own code? Record the observed defects before assigning causes, since the location of a fix doesn't necessarily tell us where the problem originated. If the framework worked well for other projects, what made it work there? Did they run into the same trouble? One difficult project doesn't prove the entire foundation is flawed.
Both sides of the table should explain their version. Sophia should illustrate the earlier decisions and constraints that engineers might have missed. Engineers should then explain the concrete problems they have been facing. Once the problem is understood, we can come up with a decision document.
We don’t need a rewrite for a few defects. We can repair or improve the existing framework. If those repairs are increasingly expensive, then maybe we can use a small alternative to see how it can work. Our comparison should weigh implementation effort, migration costs, regression risks, and future maintenance. Someone who wasn't part of the earlier dispute should review the document and decide which way to go, provided they have the authority to revisit leadership's decision.
There’s an interesting question here about leadership. If they end up deciding to replace the framework, would that mean admitting failure or demonstrating technical judgment? Most companies say they value learning. Many don’t. They even expect people like Sophia to be right most of the time. If Sophia gets recognized for defending her framework but criticized for changing her mind, we've effectively taught her which behaviour the organization expects. Ultimately, incentives drive behaviour, regardless of what we claim to value.
In the end, Sophia might still be right. Maybe, the engineers didn't account for the constraints she built into the framework. Repairing might be cheaper than replacing it. This is all fine if there's objective evidence to support the decision. If Sophia had never written the framework, would the team apply the same standard of evidence to keeping it?