The AI Side Project That Got Me Promoted

i need to be upfront about something. The title is slightly misleading. i didn't get promoted. i got made redundant. But the AI side project i built at my previous job? The person who took it over did get promoted. And the version of the story i'm about to tell you is the one i wish i'd executed better, combined with what i've seen work for others since.

Because the strategy is sound. i've watched it work for a dozen people since i started writing about this stuff. The side project approach is one of the most reliable ways to make AI skills visible, and visible skills are what keep you employed and get you promoted.

Here's how it works.

Why side projects beat certifications

You can put "completed AI fundamentals certification" on your CV and it means almost nothing. Everyone and their dog has a certificate. What you can't easily fake or mass-produce is a working project that solved a real problem.

When i was still working as a data scientist, the thing that got me attention wasn't my qualifications (everyone on my team had similar ones). It was a small tool i built that automated the weekly client satisfaction scoring. Nobody asked me to build it. I saw a gap, spent a few evenings on it, and then showed it to my manager. That tool got mentioned in two quarterly reviews, a board presentation, and became the standard process for the entire department.

The work itself was maybe 15 hours total. The career impact was disproportionately large.

This is what happens with visible, useful AI projects. They punch above their weight.

Picking the right project

This is where most people go wrong. They pick a project that's technically impressive but doesn't solve a problem anyone cares about. Or they pick something too ambitious and never finish it. Or they pick something that's useful only to them.

The right project has three characteristics:

It solves a pain point that multiple people feel. Not just your pain point. A shared one. Something your team complains about. Something that comes up in meetings. "This report takes forever." "We never know which leads to prioritise." "Nobody reads the monthly summary because it's 40 pages long." Listen for these complaints. They're project opportunities in disguise.

It's small enough to build in a week or two. This isn't your life's work. It's a prototype. A proof of concept. Something you can build in your spare time (or a dedicated evening or two if you follow the one-evening project approach) and demonstrate quickly. If your project plan has more than five steps, it's too big. Cut it down.

The output is visible and shareable. An internal tool nobody sees doesn't help your career. The best projects produce something you can demo in a meeting, share in a Slack channel, or reference in a performance review. Think dashboards, automated reports, workflow tools, or templates that teams can adopt.

Here are some projects i've seen work brilliantly:

• An automated weekly competitor analysis summary (previously took someone 6 hours, now takes 30 minutes of review time)
• A prompt library for the sales team that standardised how they used AI for outreach
• An AI-powered FAQ bot for a customer service team, built using their existing knowledge base
• A meeting notes automation that sent structured summaries and action items to all participants
• A document template generator that created first drafts of proposals from bullet-point inputs

None of these required advanced technical skills. All of them solved visible problems. All of them got people noticed.

Getting stakeholder buy-in (without asking permission)

Here's a tactical choice you need to make: do you ask for permission first, or do you build the thing and then show it?

My advice: build it first. But do it smartly.

If you go to your manager and say "I'd like to spend time on an AI project," you'll likely get one of two responses. Either "we don't have budget/time for that" or "sure, put together a proposal." The first one kills your project. The second one turns it into a bureaucratic exercise where you spend more time writing the proposal than building the thing.

Instead, build a working prototype on your own time. Get it to the point where you can demonstrate it in five minutes. Then show it to your manager as a thing that exists, not a thing you'd like to create.

"Hey, i built something over the weekend that automates our weekly competitive report. Takes about 30 minutes instead of 6 hours. Want to see it?"

No manager in the world says no to that. You've removed all the risk. The thing already works. You've invested your own time (which shows initiative). And you're offering them a win they can take credit for.

The key phrase is "I built something." Not "I want to build something." Not "Can I have permission to try something?" Present the finished product. Let them react to a thing that works rather than an idea that might not.

Making sure people notice

Building the project is half the battle. Making sure the right people know about it is the other half.

This isn't about self-promotion. i'm British, i understand the discomfort. It's about visibility. If a tree falls in the forest and nobody's in the performance review meeting to hear it, it didn't fall.

Demo it at a team meeting. Five minutes. Not a presentation with 20 slides. A quick live demo. "I want to show you something I've been working on. Here's the problem it solves, here's how it works, here are the results." Keep it short and practical.

Offer it to others. "Anyone else want to use this? I can set it up for you." Now it's not your personal productivity hack. It's a team tool. And you're the person who created it and can support it.

Write a brief internal post. If your company uses Slack, Teams, or any internal communication platform, write a short post about what you built and why. Not a brag. A share. "Built a quick AI workflow for the weekly report — saves about 5 hours. Happy to show anyone how it works." i've seen these posts get shared upward to senior leadership more than almost anything else.

Mention it in your 1:1s. When your manager asks what you've been working on, include it. Every time. "The AI workflow I built is saving the team about 20 hours a month now. Sarah and James are both using it." Repetition creates awareness.

Link it to business outcomes. Don't say "I built a cool AI thing." Say "I built a workflow that saves 5 hours per week per person, which across the team is equivalent to freeing up one full-time equivalent." Speak in the language your organisation values — time, money, quality, risk.

Handling the politics

Not everyone will be thrilled about your AI side project. Some things to watch for:

The threatened colleague. If your project automates something that was someone else's main responsibility, tread carefully. Don't position it as replacing their work. Position it as freeing them up for better work. Better yet, involve them in the project.

The sceptical manager. Some managers feel threatened by direct reports who show too much initiative. If you sense this, frame the project as "supporting the team's goals" rather than "something I did independently." Give them credit for "creating an environment where this kind of innovation happens."

The IT department. They may have concerns about tools you're using, data security, or integration with existing systems. Take these seriously. Engage with IT early if your project touches any company systems. "I built this prototype and I'd love your input on how to make it secure and compliant" is much better than having IT shut you down after launch.

The "that's not your job" reaction. Some organisations have rigid role boundaries. If you hear this pushback, reframe: "You're right, this started outside my core responsibilities. But it's saving the team significant time and I think it demonstrates the kind of cross-functional thinking the company values." Most organisations say they value initiative, even if they don't always mean it.

Building a portfolio of wins

One project is a fluke. Two is a pattern. Three is a reputation.

Don't stop at one. Once you've got the first project running, start thinking about the next one. Different problem, different stakeholder group, different part of the business if possible.

Over six months, aim for three visible AI projects. That gives you:

• A track record, not just a single achievement
• Multiple stakeholders who've benefited from your work
• Evidence for performance reviews that's impossible to ignore
• A reputation as the person who makes AI actually useful

This is what i mean by becoming the AI person on your team. Not through certificates or courses. Through visible, practical, useful work.

The project that got away

i said at the start that my story didn't end with a promotion. Here's what happened.

i built an AI tool that automated significant parts of the reporting pipeline. It worked well. My manager liked it. It got presented to the leadership team. But then the restructuring was announced, and the consultants came in, and my tool became evidence that the work could be automated — which was used as justification for reducing headcount.

The mistake i made was building the automation without repositioning my own role. I freed up time but didn't visibly fill it with higher-value work. I created the tool and then kept doing the same job, just faster. That made me efficient but also made my role look smaller.

The person who inherited my tool did it right. She used it as the foundation for a broader analytics capability, positioned herself as the AI lead for the department, and made sure everyone knew she was the one who could build more tools like it. She got promoted six months later.

The lesson isn't "don't build things." The lesson is: build things, and then use them to expand your role, not shrink it.

Start this weekend

1. Identify one problem your team complains about regularly.
2. Spend an evening building a prototype solution using AI tools.
3. Get it working well enough to demo.
4. Show your manager on Monday.
5. Offer it to the rest of the team.
6. Document the win.

That's how careers are built in 2026. Not by waiting for permission. By building things that work and making sure the right people see them.