How to Get Manager Approval for Engineering Side Projects at Work: A Framework for Getting Buy-in for Technical Improvements
Learn how to get manager approval for engineering side projects at work. A proven framework for getting buy-in for technical improvements that benefit your team and advance your career.
I had an idea to fix it. A tool that could automate most of the work. I pitched it to my manager.
He said no.
"Focus on your game. We need you to finish early."
The logic made no sense to me. Other disciplines weren't going to finish early anyway. And even if we did, there would just be another game waiting. Why not fix this problem for everyone, forever?
So I did two things. I worked on the tool anyway without telling anyone. And I kept asking. My manager. Their manager. Their manager's manager.
It took almost a year before leadership finally cared enough about the translation problems to greenlight my project. By then, I had a proof of concept that saved 50% of our translation work. When it became a full project with dedicated time, we hit 90% savings within another year.
Today, it's a flagship internal process with a dedicated team. It saves the company thousands of hours annually.
But here's what I learned through that frustrating year of rejection: I was asking the wrong question. And my manager was answering a question I never actually asked.
Why Engineering Side Projects Get Rejected (And Why Google's 20% Time Failed)
When you ask to work on a side project, you think you're proposing innovation.
Your manager thinks you're asking to abandon ship.
This disconnect is why even the most famous side project policy in tech history ultimately failed. Google's "20% time" launched Gmail, Google News, and AdSense. Products that generated billions in revenue and transformed how millions of people use the internet.
But by 2013, the program was effectively dead. Former Google employees described it as "120% time" because engineers could only work on passion projects by putting in extra hours beyond their regular workload. Only about 10% of engineers consistently used the program, according to internal reports.
What happened? As Google grew and quarterly earnings pressure mounted, managers prioritized immediate deliverables over speculative innovation. Engineers struggled to balance core responsibilities with side projects. There was no formal tracking, no resource allocation, and no protection for the time.
The same pattern plays out in engineering teams everywhere. Side projects sound great in theory. But when your manager is measured on shipping features and hitting deadlines, your proposal to work on something else sounds like a threat to their goals.
Understanding this dynamic is the first step to changing the conversation.
The Communication Gap That Triggers Automatic Rejection
You say: "I want to build this tool that could help everyone."
They hear: "I want to work on something that isn't your priority while you're trying to hit your goals."
You think: "This will save us so much time in the long run."
They think: "I need you focused on what's due next quarter, not a speculative project with uncertain payoff."
You believe: "I'm proposing valuable innovation."
They believe: "You're asking for permission to not do your actual job."
This is the communication gap that kills engineering side projects at work before they even start. You're excited about the solution. Your manager is worried about protecting their current commitments.
Most communication problems in leadership stem from this same root cause. You think you're being clear. But your message gets filtered through your manager's context, priorities, and pressures that you may not even see.
Neither of you is wrong. You're just solving completely different problems.
What I Got Wrong About Getting Buy-in for Technical Improvements
Looking back at my translation tool saga, I made four critical mistakes that extended my timeline from weeks to a full year.
Mistake 1: I Pitched My Solution Instead of Defining Their Problem
My manager already had a way to handle translations. It was painful and slow, but it was predictable. They could plan for it. They understood the resource requirements.
My new tool? Completely unpredictable. Unproven. A risk to the schedule.
I should have led with: "Translation integration costs us 800 hours per game. It blocks other teams from starting their work. It's making us miss certification windows and delaying releases. Here's what it's specifically costing you."
Why the problem exists. Then what you can do about it.
When you start with the solution, managers evaluate it as a nice-to-have. When you start with the problem, they evaluate it as a must-fix.
Mistake 2: I Didn't Quantify the Cost of the Current Approach
"Everyone hates this process" isn't data.
"We spend 800 hours per game on translation integration and it delays release by two weeks" is data your manager can actually use.
Managers care about things that affect their goals and their metrics. Show them how the current problem is already hurting what they're measured on. Make it concrete.
If you can't quantify the cost, you haven't done enough research to pitch the solution yet.
Mistake 3: I Framed It as Either/Or Instead of Both/And
I presented it as: "Can I work on this instead of my game?"
I should have framed it as: "I can do this without impacting the game schedule. Here's the 5 hours per week I have available because other disciplines are blocked waiting on their work. Here's the checkpoint at one month where we evaluate if it's working. If it's not delivering results by then, I stop."
Make it concrete. Remove the perceived risk. Give them an off-ramp.
Treating decisions like testable hypotheses instead of permanent commitments makes it easier for managers to say yes to experiments.
Mistake 4: I Fought at the Wrong Organizational Level
My direct manager didn't care enough about translation integration. It wasn't their problem to solve.
Their boss's boss cared deeply. Studio-wide efficiency? Reducing bottlenecks across multiple teams? That mattered at their level.
Sometimes the thing that's not important to your manager is absolutely critical to someone two levels up. Work with your manager to escalate to the person who actually owns the problem you're trying to solve.
Going around your manager damages trust. Working with them to find the right stakeholder builds it.
The Framework That Actually Gets Engineering Side Projects Approved
After coaching dozens of engineers through this exact challenge, here's the framework that consistently works for getting buy-in for technical improvements.
Step 1: Define the Problem, Not Your Solution
Write down what's broken. Be specific. What does it cost in time, money, missed deadlines, or team morale? Who does it affect? How often does it happen?
Your manager needs to care about the problem before they'll care about your solution. If you can't make them feel the pain of the current state, they won't invest in changing it.
Step 2: Show How It Protects Their Goals
Your manager is measured on something. Shipping features on time. Reducing bugs. Improving team velocity. Hitting revenue targets.
Show them how fixing this problem helps them hit their targets. Or at the very minimum, show them it won't hurt their ability to deliver.
Connect your technical improvement directly to their business priorities. This is how you transform a side project into strategic work.
Step 3: Make It Low-Risk With Clear Checkpoints
Give them a specific time commitment. A clear checkpoint to evaluate progress. An off-ramp if it's not working.
"I'll spend 5 hours per week for the next month building a proof of concept. At the end of the month, we'll review the results together. If it's not showing measurable improvement, I stop and return full focus to primary projects."
This removes the fear that you'll disappear down a rabbit hole for six months with nothing to show for it.
Step 4: Create Visuals That Make the Problem Concrete
I wish I had done this earlier in my translation tool journey. A simple diagram showing current state versus future state makes the problem real in a way that words never can.
Show the workflow. Show the bottlenecks. Show where time gets wasted. Then show what it could look like.
Visuals make abstract technical concepts concrete for non-technical stakeholders. They also force you to think more clearly about the actual problem you're solving.
Step 5: Find the Right Stakeholder
If your manager doesn't care about the problem, ask them who does. Work with them to escalate.
"I understand this isn't your top priority right now. Who in the organization would care most about reducing our translation overhead? Can you help me get 15 minutes with them to present this?"
This approach respects your manager's time and priorities while still moving your initiative forward.
The Language That Changes the Conversation
The difference between getting shut down and getting approval often comes down to how you frame the initial ask.
Weak framing: "Can I work on this side project to improve our translation process?"
Strong framing: "Translation integration is costing us 800 hours per game and delaying releases by two weeks. I think I can cut that by 50% without impacting my current project schedule. Can I spend 5 hours a week for the next month building a proof of concept? If it's not working by then, I'll stop."
Weak framing: "I have this cool idea for a tool that could help the team."
Strong framing: "Here's the problem: we're spending 40 hours per sprint on manual configuration that could be automated. Here's what it's costing us: delayed feature delivery and increased bug rates. Here's my proposal: 6 hours per week for 6 weeks, with a demo at week 3. Does this solve a problem you care about? If not, who should I talk to?"
Weak framing: "Why won't management let us innovate?"
Strong framing: "I want to make sure I'm solving the right problems. What are the top three things keeping you up at night right now? If this isn't one of them, let's talk about how to get this in front of someone it matters to."
Notice the pattern. You're not asking for permission to do less work. You're proposing a solution to a problem that's already costing the team, with a clear plan and defined checkpoints.
Why Engineering Side Projects Matter for Your Career
The research on career development is clear. Professional relationships drive career advancement more than technical skills alone. But side projects serve a different critical function.
Side projects are where real innovation happens. They're where you develop skills that set you apart. They're where you build things that make your impact visible across the organization.
According to research on workplace innovation, companies that successfully implement side project programs see significant benefits. Atlassian's "ShipIt Days" resulted in major improvements to their core products. Over 60% of side project ideas eventually made it into production at companies that tracked outcomes systematically.
But more importantly for your career, side projects are how you demonstrate leadership before you have the title. When you identify a problem, build a solution, and get organizational buy-in, you're showing exactly the skills companies look for in senior engineers and engineering managers.
The ability to see beyond your immediate tasks, identify systemic problems, and drive solutions through an organization is what separates individual contributors from leaders.
What to Do Next Week
Before your next conversation about a side project or technical improvement:
Monday: Define the problem, not your solution. Write down what's broken, what it costs, and who it affects. Make it concrete with real numbers.
Tuesday: Research how this problem impacts your manager's goals. Connect your proposed improvement to their priorities and metrics.
Wednesday: Outline your low-risk proposal. Specific time commitment, clear checkpoints, defined off-ramp. Make it easy for them to say yes to an experiment.
Thursday: Create a simple visual. Current state versus future state. Show the bottlenecks and the proposed improvements.
Friday: Identify the right stakeholder. If your manager doesn't own this problem, figure out who does. Prepare to work with your manager to escalate appropriately.
Then have the conversation. Not "Can I work on this cool thing?" but "Here's a problem costing us X. I can fix it with Y time commitment without impacting Z. Here's how we'll know if it's working. Does this solve a problem you care about?"
The Real Value of Side Projects
Side projects aren't time wasted. They're where innovation comes from. They're where you develop skills that accelerate your career. They're where you build systems that multiply your impact.
But your manager can't see any of that if you're asking them to choose between your idea and their goals.
Show them it's not a choice. Show them it's both.
The translation tool I fought for over that frustrating year became one of the most impactful things I built in my entire time at that company. It saved thousands of hours. It reduced stress for dozens of teams. It became a model for how we approached process improvement across the studio.
But I could have gotten there in one month instead of twelve if I had known how to frame the conversation correctly.
You already know how to build the solution. Now you know how to get permission to build it.
What engineering side project are you trying to get approved right now? What's the real problem you're trying to solve? Share in the comments below.
You're great at the work. Let's make it visible.
If you're struggling to get buy-in for ideas that could make real impact, or if you want to improve how you communicate technical value to leadership, let's talk. I help tech and systems leaders communicate their value and grow without burning out.
Comments
Post a Comment