The Problem with Shadow Development

You have 1 article left to read this month before you need to register a free LeadDev.com account.

Estimated reading time: 5 minutes

You’ve heard of ‘Shadow IT’, where white collar workers’ use unauthorized tools to bypass company-approved enterprise software.

But what about ‘shadow development’, where software developers prefer unsanctioned tooling, frustrating their managers and creating serious cybersecurity risks. 

One tech entrepreneur recently wrote on Reddit that every engineer he knows “has either built or adopted” a workaround for the tools provided by their company. “Not because they want to be rebels,” he added, “but because they’ve been failed by tools that prioritize process over progress.”

That balance gets to the heart of the shadow development dilemma. On top of the friction getting in the way of engineers’ day-to-day output is a communication breakdown between different levels of the organization. It’s a dynamic that leaves middle managers with a careful line to walk.  

The search for simpler solutions

Shadow development arises from engineers’ frustration with inefficient systems. 

While Darian Shimy was the VP of engineering at Weebly, his dev team used a Google Sheet titled “Reality Tracker” instead of their mandated Jira workflow to track project progress. They found that the spreadsheet was significantly cleaner, faster, and updated in real time, which eliminated the need to click through numerous subtasks to find key information.

“We even had an experienced dev on the team who built a quick CLI script to post updates to Jira to ensure we wouldn’t get flagged for being inactive,” Shimy recalls.

Israel Gaudette, the Quebec-based cofounder of Custom Workflows, has encountered similar workarounds among several of his clients.

“We worked with a dev team that stopped using their company’s official tracking tools altogether – instead, they used a Notion board labeled “Actual Tasks” and relied on Slack threads for real-time updates,” Gaudette says. “Jira was still technically in use, but only through a command-line bot that posted updates automatically.” He recalls that another team ran their own CapRover instance for internal workflows and used Discord to share deployment updates.

Managers’ responses varied. Some never noticed their teams’ workarounds in the first place, while others found out and embraced them. “One team lead we worked with fully switched to the workaround their devs had set up,” Gaudette recalls. “Notion and Slack became the new standard because they were getting faster, cleaner status updates than with the original stack.”

Hone John Tito, cofounder of Game Host Bros based in Hamilton, New Zealand, is another manager who embraced his dev team’s clandestine solution to a stubborn project management problem. 

While the company’s officially-sanctioned enterprise tool worked well, its architecture didn’t totally align with the team’s working style. “To bridge the gap, they secretly introduced Trello alongside the approved system, using it as a visual, day-to-day task tracker that complemented the primary tool’s role in long-term planning and reporting,” Tito says. 

Instead of getting upset over his team’s secret troubleshooting methods, Tito welcomed their solution. “We need to find tools that are appropriate for our team, since they ought to get a chance to create systems that are uniquely theirs,” he explains. That flexibility paid off. Within a month, the amount of time the team spent on internal task updates dropped by about 40%. 

When Shimy eventually caught on to his Weebly team’s Google Sheets hijinks, his response was similarly forbearing. “I wasn’t mad because I understood it,” he says. “Tools need to serve the team rather than the other way around. With that said, I told my team to run these things past me.” 

Getting everyone on the same page

It’s up to developers to notify their managers of pain points – ideally, before they implement their own solutions. This gives managers a window into what the team is up to, while also helping to ensure that proper security protocols are being met. But it’s the responsibility of managers to set the stage.

Engineering leaders must not only communicate their willingness to be flexible around their developers’ tools and systems, but they must also take their developers’ frustrations about those tools and systems to heart. “If a tool is so hard to use that people don’t use it, respect that,” says Marcus Merrell, the San Francisco-based Principal Technical Advisor for Sauce Labs. 

Better still, engineers should have a say in which tools they do use.

“By creating your own tools, you consolidate all your action items into one place, and track your work in a way that works for your brain,” says Kate Broeking, cofounder of the workplace coaching firm ThynkStack and founder of Amazon’s Work Wellness Coaching program. “For some devs, writing ‘build authentication flow’ works, but for others, they need it broken down into the first actionable step, like ‘set up user table schema.’”

Broeking says that it’s the mark of a good manager to recognize that everyone works differently and needs to use the tools that match their work style best. “We encourage employers to authorize the use of a variety of third-party apps and software. If Asana is approved, why not Notion? Or Obsidian? That way employees can choose what’s best for them.” 

This approach leaves managers having to weigh up the cost of licensing multiple enterprise platforms against any potential efficiency and morale gains. 

It’s also the more secure approach. An IBM report found that shadow data was involved in one-third of corporate data breaches in 2024, costing companies an average $4.9 million – up 10% from the year before. 

Gaudette proposes a compromise. “The best approach we’ve seen is to let developers shape the tools they use, then build reporting layers on top,” he says. “Platforms like Cloudron or Coolify make it possible to self-host lightweight systems that devs actually like using, while still giving managers the visibility they need.”

As Shimy sees it, being an engineering manager means understanding that workflow and processes may be subject to change. If his team comes to him with an idea in mind, he tries to hear them out and give them the reins to do what they think makes sense. 

“I’ve learned that friction breeds workarounds,” says Shimy. “If your tools create more work than they save, your team will find or build something better.”