The Harsh Truth. What We’re Learning About Driving Engagement in Internal Projects

Odin’s Spear — a Python package designed to let anyone in the company automate repetitive tasks and streamline their workflows.

It was fast. Powerful. Time-saving.

I imagined engineers across the business picking it up, writing a few lines of code, and shaving hours off their week.

That didn’t happen.

What I learnt — slowly and painfully — is that most people don’t want to write code.

They want the outcome, but not the learning curve.

Even showing them a task drop from hours to seconds wasn’t enough to get them over the line.

I thought they’d be as excited as I was.

But code isn’t exciting to everyone. A terminal prompt can feel like a brick wall. People are busy. They don’t want to learn new tools — they want solutions.

That was our wake-up call.

So we started adapting. We took the automation we’d built and began wrapping it in simpler, more accessible interfaces.

Think GUIs. Forms. Clean hand-offs. Tools with buttons and inputs, not code blocks.

We’re now in the middle of a major transition — from code, to low-code, to no-code.

We introduced Docker to eliminate setup pains and reduce friction — most automations now run with a single command.

We’re also starting to build internal web apps that sit on top of our Python tooling — these will be our future.

Still powerful under the hood — but invisible on the surface.

We haven’t cracked full adoption yet, but this shift has helped us build momentum. We’ve found early adopters. We’ve inspired some colleagues to start learning Python. And we’ve picked up a few big wins that showed us what actually works when it comes to internal engagement.

We could’ve mandated use through policy — but we didn’t. And I’m glad. The users we do have are believers. They want to be here. And their enthusiasm goes further than anything top-down ever could.

When I built Odin’s Spear, it was a side project. But my manager saw the potential, shared it with others, and backed it fully.

That support changed everything — it’s the reason I now lead the Software Development team at the company.

What started as a side experiment is now a full-time focus with dedicated people, direction, and support.

This one was hard. But if your goal is adoption, not conversion, you have to meet people where they are. People trust interfaces. They fear code. So give them buttons — even if your team is proud of what’s behind the scenes.

We show our work — constantly. Demos, walkthroughs, screenshots. If you’re not in front of people, you’re forgotten. And when you show, always explain why it matters.

When someone suggests an idea and it ships, they don’t just feel heard — they become your next advocate. Internal work needs internal UX. Otherwise, it’s just noise.

When someone shows genuine interest, lean in. Ask them to test, to share, to help shape direction. Bring them into the process. They’ll spread the word far better than a Slack post ever will.

We’re still building. Still learning. Still failing sometimes.

But the progress is real. From a single Python package to a full software team. From scripts to Docker. From command lines to web apps.

We’ve stopped trying to convert everyone.

Instead, we focus on serving the right people well — and using that momentum to grow.

If you’re working on internal automation, enablement, or tooling, and struggling to get traction: you’re not alone. The path is rarely smooth. But it’s worth it.

And if you’ve found smart ways to drive engagement in your org, I’d genuinely love to learn from you.