Usually, when you think of a software engineer, you picture someone quietly typing lines of code, solving bugs, and sipping coffee. But behind that calm screen is often a storm of office policies, manager expectations, and impractical workflows.
For instance, an engineer shared their wild ride with a company policy that sounded good on paper but made zero sense in practice. It demanded every single code change be deployed across all servers within two weeks or get explicit managerial approval. Instead of ignoring the rule, they followed it to the letter, forcing approvals for every update and documenting the chaos. What followed was a masterclass in malicious compliance: one that didn’t just highlight the policy’s flaws, but ultimately forced leadership to scrap it entirely.
Software engineers often face rigid policies that end up hindering rather than helping their work
Image credits: Jordan González / Unsplash (not the actual photo)
One employee shared how they received an exemplary performance review after using malicious compliance to successfully challenge and eliminate a flawed policy
Image credits: ArthurHidden / Freepik (not the actual photo)
Image credits: cottonbro studio / Pexels (not the actual photo)
Image credits: LaconicLacedaemonian
Image credits: Getty Images / Unsplash (not the actual photo)
Navigating management decisions can be tricky and may sometimes interfere with getting the actual work done
Working at a large company has its perks. One of the biggest advantages is being part of a strong, supportive community. You also gain access to better tools, structured processes, and the opportunity to collaborate with talented professionals across departments. There’s often a sense of security that comes with big organizations, along with more clearly defined roles and career paths.
But it’s not all sunshine. One of the more frustrating parts can be dealing with management decisions you don’t agree with. Whether it’s rigid policies, unrealistic timelines, or out-of-touch directives, these can make daily work feel more difficult than it needs to be. And unlike smaller teams, pushing back isn’t always easy—it takes strategy, patience, and sometimes, a little creativity.
Working in the IT sector can feel like a double-edged sword, especially in large organizations. On one hand, you’re part of something big, with access to tools, processes, and people that smaller setups often can’t match. On the other hand, you’re navigating complex systems and layers of management. And when things don’t move fast enough, that advantage starts to feel like a burden. We spoke with Rinkita Mittal, a data engineer at McKinsey & Company, to understand what it’s really like on the inside.
“There’s definitely structure,” she began, “which helps with accountability. You know who’s responsible for what, and there’s a chain of communication.” But that same chain can become a bottleneck. She explained how simple requests, like a tool update or a minor data patch, can sometimes take days because of the approval loops. “It’s not always anyone’s fault. It’s just how the system is built,” she shrugged.
Hierarchy can streamline things, but it also tends to dilute urgency. When too many people are involved in making decisions, timelines can stretch unreasonably. “I’ve seen cases where we had client-side issues that could’ve been fixed in half a day, but because two teams needed to align, it took three,” she said.
Image credits: DC Studio / Freepik (not the actual photo)
Clear and open communication is essential for creating a smoother, more efficient workflow
Policy implementation is another tricky part of the job. “Sometimes a top-level policy gets introduced without understanding how it affects day-to-day workflows,” Rinkita shared. For engineers, this can be frustrating, especially when their concerns aren’t heard.
“That’s where things start to break down,” Rinkita added. “You feel like you’re putting in extra work just to feed a process that doesn’t benefit your output.” She stressed that engineers aren’t trying to avoid work, they just want their time used more effectively. And for that, communication is everything.
One thing Rinkita emphasized was the need for managers to take feedback seriously. “A lot of engineers keep quiet to avoid sounding like they’re complaining. But if there’s a bug in the system, structurally, not just in code—it has to be flagged.” She recalled instances where small backend issues became major blockers just because no one wanted to push back against policy.
But not all interactions are bad. “I’ve also had really good managers who took the time to explain why something had to be done,” she said. “When you know the ‘why,’ it changes how you approach the ‘what.’” According to her, empathy and explanation go a long way. “If I know that extra documentation helps the security team stay audit-ready, I’ll do it happily.”
Looking ahead, she believes the solution lies in collaboration. “Instead of a top-down mandate, it’s better to bring in engineers early in the planning stage.” That way, potential roadblocks can be identified and worked around before they become real problems. At the end of the day, Rinkita believes it’s all about trust. “Trust your engineers to be professionals who care about quality,” she concluded.
In this particular case, it seems like management had to learn the hard way just how flawed their policy really was. But what about you? If you were in this situation, would you have taken the same approach? Or would you have handled it differently? Tell us how you would have dealt with a policy that looked good on paper but fell apart in reality.
People online widely agreed that the policy was poorly thought out, and the author offered even more insight into just how flawed it was
