.
Image: Illustration: Freepik
A few years ago, we had a bottleneck within our organization at Super.com, the membership program focused on saving, earning, and credit building. Every new idea depended on our engineers, and our internal requests were piling up faster than we could clear them.
We were adding new people to our company every week, but our engineering team was underwater. Every new feature, every minor internal tool, every process tweak depended on our developers. We were hiring as fast as we could, but it felt like shoveling sand against the tide.
So we tried something different. We started teaching non‑technical employees (designers, product managers, operations leads, corporate support teams) how to build their own tools and automations. At first it felt radical. Then it felt obvious.
Fast forward: we grew to over $200M in annual revenue with only about 200 people. We stopped the hiring frenzy, but the business was growing faster than ever. Along the way, we documented everything in an internal playbook for our team. Soon our LinkedIn inboxes and emails were full of messages from other leaders trying to do the same thing. Turns out the problems we had been solving weren’t unique.
Here are the five lessons that have resonated most with other leaders about empowering non‑technical teams to build their own solutions, and why they matter to any leader.
Inside our company we set up two “AI guilds”: one for technical implementation (e.g., building tools) and one focused on adoption and use cases (e.g., using tools). They met monthly, included people from every department, and shared concrete experiments. A product manager might present how she used an AI tool to understand the codebase without tapping on the shoulder of an engineer. An operations lead might show how he used a simple script to automate dispute management.
The takeaway: don’t keep AI or automation knowledge locked in engineering. Build cross‑functional forums that normalize sharing wins, questions, and learnings. Those conversations surface use cases you’d never see from the top down.
You can’t empower non‑engineers if the only tools they have require a CS degree. We invested in low‑code environments like Superblocks, Zapier, Amplitude, and Glean Agents, and we made tools that are typically only used by developers, such as Cursor (AI IDE) and Coder (Remote Environments), accessible.
Our developer operations team took on the challenge of making onboarding as simple as possible. They stripped out every unnecessary step and automated the rest, until getting set up took less than 10 minutes. We learned quickly that if a tool required more than 10 minutes of training, adoption would stall. Most non-technical teammates could follow the instructions on their own, but for anyone who preferred extra help, our IT team sat down with them one-on-one.
We published a clear internal AI policy that spelled out approved use cases (like automation scripts, bug‑fix prototypes, and research tools), quality standards (human oversight required for anything customer‑facing or that becomes part of routine process), and security guidelines (no sensitive data in prompts without review).
Engineers didn’t police these policies—they coached. Any piece of code went through review, whether it came from an engineer or not. That consistency was the point: non-technical team members could submit pull requests, and instead of dismissing them, engineers gave feedback the same way they would with peers. Coaching meant guiding contributors through fixes and best practices, not shutting the door. Guardrails, not gatekeepers, is what makes experimentation sustainable.
When someone outside engineering built something that moved the needle (like an operations process automation or AI triage of customer reported issues), we made sure everyone heard about it. These wins were shared in weekly business reviews and company‑wide meetings. That visibility did more than motivate others to try; it changed our culture. During objectives and key results planning we’d prompt each team to consider, Could AI help me hit my goals faster? Could I build this myself instead of waiting? Sharing wins turns isolated hacks created by individuals into company-wide capabilities.
When non-engineers have access to the right tools, software engineers become even more valuable. At our company, 93% of developers use AI tools daily. Engineers still own the hard, high‑impact work: major features, architecture, deep debugging. But now they spend less time answering basic questions or making tiny fixes for other teams. The result: your best technical talent gets to focus on ambitious projects, while everyone else can handle the smaller, more routine tasks themselves.
In a world where AI and low‑code tools are everywhere, the companies that win won’t just have great engineers. They’ll have a culture that empowers everyone to build.
ABOUT THE AUTHOR
Ryan Fox is the CTO of Super.com, the world's most valuable membership program, focused on saving, earning, credit building, and more. Before joining the company in 2015, Ryan was a Senior Software Engineer at Google.
FAST COMPANY