Today, we’re thrilled to sit down with Anand Naidu, a seasoned development expert with extensive knowledge in both frontend and backend technologies. With a deep understanding of various coding languages, Anand has seen firsthand how software development processes evolve, impact speed, and shape team dynamics in organizations of all sizes. In this interview, we’ll dive into the challenges of governance in scaling companies, the importance of clear ownership, strategies for maintaining efficiency, and the cultural toll of overcomplicated processes. Let’s explore how engineering leaders can strike the right balance between structure and speed.
How do governance processes in larger organizations often become a bottleneck for software development?
I’ve noticed that as organizations grow, the layers of governance tend to multiply, often with good intentions like ensuring quality or preventing outages. But these layers can slow things down significantly. For instance, a simple code change that takes 15 minutes to write might sit in review for two weeks because it needs sign-offs from multiple teams or committees. The more people involved, the more diluted responsibility becomes, and suddenly, no one feels urgency to move it forward. It’s a classic case of diffusion of responsibility—everyone assumes someone else will handle it.
Can you share a specific moment from your career where an approval process caused an unnecessary delay in a project?
Absolutely. Early in my career, I worked on a project where a minor configuration update got stuck in a review cycle for over a week. The change was low-risk, but it required approval from a security team that only met once every two weeks. By the time we got the green light, the feature it supported missed a critical launch window. It was frustrating because the delay didn’t improve the outcome—it just cost us momentum. That experience really highlighted how processes can outlive their usefulness if they’re not regularly reevaluated.
How have you seen governance and approval mechanisms change as companies scale, and what usually triggers those changes?
When companies are small, governance is often minimal—decisions are fast because ownership is clear and trust is high. But as teams grow past a few hundred engineers, incidents like outages or security vulnerabilities often prompt leadership to add oversight. For example, after a deployment causes a major issue, you might see new architectural review boards or mandatory security checks for every change. These additions make sense in the moment, but over time, they stack up without anyone questioning if they’re still needed. It’s often driven by a fear of repeating past mistakes rather than a clear-eyed look at current risks.
Why do some processes linger in organizations even when they no longer serve a purpose?
A lot of it comes down to inertia. Once a process is in place, it becomes a tradition, and people stop questioning it. I’ve asked teams why a certain approval step exists, and the answer is often, “That’s just how we’ve always done it.” There’s also a psychological safety net—having a process, even an outdated one, feels like a defense against blame. But this can create barriers that frustrate engineers and slow down delivery without adding real value. It’s a trap many organizations fall into without realizing it.
How critical is clear ownership in maintaining speed on software projects, and what happens when too many people are involved in decision-making?
Clear ownership is everything. When one or two people are explicitly accountable for a project or change, decisions happen faster because there’s no ambiguity about who’s driving the outcome. But when you have too many cooks in the kitchen—say, 10 reviewers on a single pull request—things grind to a halt. Everyone assumes someone else will catch issues or give the final nod, and merge times drag on. I’ve seen studies showing that repositories with more than 10 owners take three times longer to merge changes compared to those with just a couple. It’s a direct correlation between diffused accountability and delays.
What strategies have you found effective for balancing the need for multiple reviewers with the goal of keeping decisions quick?
The key is to keep reviewer circles small and purposeful. For most changes, two to three reviewers with direct context are enough. If broader input is needed, use tools like decision records to share context without requiring everyone’s sign-off. I also advocate for setting short comment windows—maybe a couple of days max—and designating one person as the final decision-maker. This avoids the endless wait for consensus, which can kill momentum. It’s about trusting your team to focus on what matters rather than chasing universal agreement.
How can teams ensure that low-risk changes, like documentation updates, don’t get bogged down in lengthy review cycles?
Teams need to create fast lanes for low-risk work. Changes like documentation, test updates, or reversible configs shouldn’t go through the same rigorous cycles as, say, a major architectural shift. I’ve seen success with single-reviewer approvals or even automated checks for these types of updates. Tools that scan for issues in the background can also help—think automated linting or security checks that flag problems without human intervention. By clearly defining what qualifies as low-risk, you free up time for the stuff that truly needs deep scrutiny.
What role does escalation play in unblocking stalled decisions, and how can teams foster a culture where it’s seen as a positive step?
Escalation is a powerful tool when decisions stall, but it’s often underused because people worry it signals conflict or failure. In reality, it’s about efficiency. I’ve had to escalate decisions to a lead or architect when a review lingered past our team’s expected timeline, and it almost always resolved the issue quickly. To make escalation a norm, leaders need to frame it as a collaborative move—praise it as a way to keep projects on track rather than a last resort. Setting clear review SLAs also helps, so everyone knows when it’s time to bump an issue up the chain.
What impact have you seen on team morale and innovation when governance becomes overly complex or layered?
It’s incredibly corrosive. I’ve watched talented engineers lose their enthusiasm when they spend more time navigating reviews and stakeholder feedback than actually building. When a feature takes months to ship because of endless cycles, the original creator often doesn’t even recognize their work by the end. Worse, it shifts focus from crafting elegant solutions to just getting approvals. Innovation dies because the cost of proposing bold ideas feels too high. The best engineers start to disengage—or leave—when they feel like they’re playing alignment games instead of creating impact.
Looking ahead, what’s your forecast for how governance in software development will evolve as organizations continue to scale?
I think we’ll see a stronger push toward adaptive governance—processes that are designed to evolve rather than fossilize. Organizations will increasingly use data, like merge times and review latency, to regularly audit their rules and prune what doesn’t work. Automation will also play a bigger role, embedding checks into workflows so manual reviews can focus on high-impact decisions. Ultimately, I believe the most successful teams will prioritize trust and autonomy, aligning governance with team maturity and system boundaries. It’s about enabling speed and confidence, not just adding more gates.
