Most engineering leaders have a very known and very annoying "normal error." It's the log entry or deployment glitch that has been around so long that it is simply accepted as part of the status quo.
Jeff Schnitter, a Solution Architect at Cortex, describes this as a form of organizational Stockholm syndrome. This mindset is unsustainable for several reasons. When teams stop questioning inefficient rituals, small problems eventually reach a crescendo where the ticking time bombs in the codebase can no longer be ignored.
It's abundantly clear that engineering leaders need to overhaul this culture, but this transformation won't happen through top-down mandates. Instead, leaders are asking simple questions about what currently sucks about their teams' daily workflows and building momentum through small, incremental wins. Jeff and Ganesh Datta, the co-founder and CTO of Cortex, recently sat down on the Braintrust podcast to discuss how leaders can begin this work and find the root causes of developer friction.
Focus on the pain instead of the solution
It's easy to get caught up in the latest tools or methodologies. Jeff believes that successful change starts with a more grounded observation. "I always want to start with the pain," he explains. "People understand the pain they have, and when they articulate it, you can identify what is preventing them from accomplishing their goals."
Jeff believes that new hires are particularly valuable for this reason. They still have an outsider's lens that allows them to see the organization clearly. If you encourage them to speak up early, you can fix those problems before they also learn to just live with them.
"I'm sure you've worked in places where people say, 'Yep, that error is normal. You just overlook that. That's just the way it is,'" Jeff continues. "You have to avoid that. You have to question everything that you do all the time."
Culture is about alignment on outcomes
It's easy to fall into the trap of trying to standardize every tool and process across a large organization. Jeff learned the hard way that telling engineers how to run their business is a quick way to create resistance. He also realized that the specific tools a team uses are far less important than the results they produce. If a team is shipping high-quality code with high reliability, it should not matter if they prefer a different review tool than the team next door.
"If you agree that there are some non-negotiables that you have to adhere to, fine, but if you can reach that goal, it is okay to have that variability." — Jeff Schnitter, Solution Architect, Cortex
Jeff suggests that leaders should stop fighting the standardization battle. "Instead of trying to fight that problem, allow these teams to run independently and prove through data what works better," he adds. "Having a shared definition of what it looks like and feels like is important so you have confidence in what you're building and deploying without fear."
Aligning incentives through service ownership
Cultural shifts often fail because the incentives for individual teams aren't in sync with the goals of the organization. Jeff says that teams naturally prioritize reliability when they own a service through its entire lifecycle. If a developer is responsible for a service once it reaches production, they have a personal stake in making the deployment process as smooth as possible.
"You've seen cases where you own a service and then maybe you throw it over the wall. The team that builds it is not necessarily incentivized to make sure that it's an efficient deployment or easily supported after it's deployed." — Jeff Schnitter, Solution Architect, Cortex
This level of ownership makes the value of addressing technical debt much more obvious. Instead of viewing reliability as a chore, it becomes a practical way to avoid a late night alert. When the person building a feature is also the one supporting it, the motivation to build something robust is built directly into their workflow.
The role of the leader as a coach
Engineering leaders often feel the need to stay in the middle of every tactical decision. Jeff says the ideal leader is more like a basketball coach who puts in the hard work during practice but stays on the sidelines during the game. The leader's job is to define the vision and set clear goals for the organization. Once those are established, they have to trust their teams to execute the rituals and solve problems independently.
Great leaders also focus on where the organization needs to be in six months instead of just reacting to the issues of the day. "A quarterback's gotta throw to where the wide receiver's gonna be, not where they're at," Jeff continues. "When I think about working with an organization, where are we going to be in six months? I want to be throwing the ball to that point." By anticipating challenges before they become emergencies, engineering leaders can help their teams move away from a reactive state and toward a more predictable future.
You can hear more about Jeff's experiences at Workday and his thoughts on cultural change in the latest episode of Braintrust.
