As engineers, we are trained to solve complex technical problems. We can spend weeks designing a scalable system, optimizing a database query, or refactoring a legacy module. We find elegance in well-written code and robust architecture. But I have seen more technically sound projects fail for social reasons than for technical ones. They fail because the engineers behind them could not build a compelling case for why the work mattered.
After few years of leading teams, I've learned a hard truth: the best code doesn't always win. The best-communicated idea does. When you propose a project, you are not just writing a technical design document. You are competing for a finite pool of resources: time, money, and people's attention. Your proposal for a database upgrade is up against the product manager’s new shiny feature and the marketing team’s A/B testing framework.
To win, you need to step outside the IDE and learn to speak the language of the business. You need a framework to translate your technical vision into a value proposition that resonates with everyone, from your product manager to the CFO. This isn't about office politics. It's about effective leadership. This is the framework I use to get critical engineering work prioritized and celebrated.
The Four Lenses of Engineering Value
Not all engineering work is created equal. The first step in building a case for your project is to understand what kind of value it delivers. Trying to sell a security upgrade with the same pitch you use for a new user-facing feature is a recipe for failure. I categorize all engineering initiatives through four distinct lenses. A single project might touch on several, but it usually has a primary one.
Lens 1: Product Enablement (The Feature Driver)
This is the simplest category to understand and the easiest to get prioritized. This is work that directly unlocks new features or improves existing ones for the end-user. Examples include building a new API endpoint for the mobile app, adding a new field to a data model, or integrating a third-party service. When you are working on product enablement, your closest ally is the product manager. Your success is measured in feature velocity and user impact.
Lens 2: Risk Reduction (The Insurance Policy)
This is work that prevents bad things from happening. It’s the digital equivalent of buying insurance. It doesn't generate new revenue, but it protects existing revenue. Examples include patching security vulnerabilities, upgrading out-of-support libraries, improving monitoring, or setting up better disaster recovery plans. This work is often invisible when done well, which makes it a hard sell. The key is to quantify the potential cost of inaction. A data breach isn't just a technical problem; it's a multi-million dollar liability and a brand disaster.
Lens 3: Efficiency Gain (The Force Multiplier)
This work makes your team, or the entire organization, faster and more effective. It's about reducing costs, either in time or money. Examples include improving CI/CD pipeline speed, automating a manual deployment process, optimizing cloud infrastructure to lower the monthly bill, or building a self-service tool for the support team. The value here is measured in developer hours saved, reduced operational costs, or faster time-to-market for everyone. This is work that pays dividends over time.
Lens 4: Strategic Positioning (The Long Game)
This is the most abstract and often the most difficult work to champion. It doesn't deliver immediate user value, prevent an imminent disaster, or save money next month. Instead, it sets the company up for future success. This includes large-scale projects like migrating from a monolith to microservices, adopting a new core technology like Kubernetes, or rebuilding the data platform to support future machine learning capabilities. These projects are foundational. They are about unlocking capabilities the business doesn't even know it needs yet. Pitching this requires a strong narrative about the future of the company and the market.
Before you write a single line of a proposal, decide which lens (or lenses) best represents your project. This choice will define your entire communication strategy.
Prioritizing Beyond Urgent vs. Important
Once you've identified the value, you need to place it on the roadmap. We've all seen prioritization frameworks, but many of them fall short for engineering because they miss a key dimension: effort. A task can be important and urgent, but if it requires six months of work from your entire team, it's a very different decision than a two-day fix.
I use a simple mental model with three axes:
- Impact: How significant is the outcome? Use the Four Lenses to define this. A project that enables a flagship feature has high impact. A project that saves $500 a month in cloud costs has lower impact.
- Urgency: How quickly will the consequences of inaction be felt? An unpatched critical security flaw is highly urgent. A plan to migrate off a legacy system that is still functional is important, but not urgent.
- Effort: How much time and how many people will this take? Be realistic. Use t-shirt sizes (S, M, L) or a rough estimate in weeks. This isn't about perfect estimation; it's about orders of magnitude.
Your goal is not just to work on high-impact, high-urgency tasks. That leads to a culture of firefighting. The real art is in balancing the portfolio:
- Quick Wins: Low-Effort, High-Impact. Do these immediately. They build momentum and trust.
- Big Bets: High-Effort, High-Impact. These are your strategic projects. You must break them down into smaller, deliverable milestones. Never propose a one-year black-box project.
- Thankless Chores: Low-Impact, High-Urgency. These are the necessary evils, like minor bug fixes or support requests. Automate or streamline them as much as possible.
- Time Sinks: High-Effort, Low-Impact. Question why these are on your radar at all. This is where pet projects and gold-plating often hide.
By explicitly mapping your work against these three axes, you can have a much more objective conversation with product and management about what to do next, and what to consciously choose not to do.
The Communication Playbook: From Tech Jargon to Business Case
Having a great idea and a solid prioritization plan is only half the battle. Now you need to sell it. This is where most engineers stumble. We are comfortable talking about implementation details but struggle to articulate the business case. Here’s a playbook for translating technical needs into a language everyone understands.
Rule 1: Frame the Problem, Not Your Solution
Never lead with your proposed solution. Nobody cares that you want to use Kafka. They care about the problem you are trying to solve.
- Wrong: "We need to implement a message queue using Kafka for our services."
- Right: "Our checkout, shipping, and notification services are tightly coupled. When the notification service has a problem, it can block customers from placing orders. This has caused two site-wide outages in the last quarter, impacting an estimated $50k in revenue."
By framing the problem and its business impact first, you create a shared understanding and a sense of urgency. The solution becomes a logical next step, not a technical indulgence.
Rule 2: Quantify Everything
Numbers are the universal language of business. Replace vague adjectives with concrete metrics. This transforms your argument from an opinion into a data-driven proposal.
- Vague: "Our CI/CD pipeline is slow."
- Concrete: "Our average build and deploy time is 45 minutes. With 10 engineers deploying twice a day, we lose 15 hours of productive engineering time daily. Reducing this to 10 minutes would save us over 300 engineering hours per month, which is equivalent to having an extra full-time engineer."
Rule 3: Tailor the Message to the Audience
Different stakeholders care about different things. A one-size-fits-all pitch will fail. You need to connect your project's value to their specific goals, using the Four Lenses as your guide.
- For Product Managers: Focus on Product Enablement and Efficiency. Frame your project in terms of feature velocity. "This refactoring will allow us to build the new personalization features 50% faster and A/B test different algorithms independently."
- For Executives and Finance: Focus on Risk Reduction and Cost Savings. Frame it in terms of money and risk. "This server upgrade will reduce our monthly AWS bill by 15% and eliminate a critical security vulnerability that could lead to regulatory fines."
- For Other Engineering Teams: You can be more technical, but still focus on the shared pain points. "By creating a shared authentication service, your teams will no longer need to maintain separate, inconsistent login logic. This will reduce bugs and simplify onboarding for new services."
A Real-World Example: The Monolith Migration
Let's put it all together. Imagine you want to propose breaking down a large, monolithic application. This is a classic Strategic Positioning project, and it's notoriously difficult to get approved.
The Wrong Pitch:
"I think we should refactor our monolith into microservices. It's a more modern architecture, and companies like Netflix and Google use it. We can use Docker and Kubernetes."
This pitch is all solution and no problem. It's full of technical jargon and relies on appealing to authority without context. It will likely be met with skepticism and questions about risk and cost.
The Right Pitch (Using the Framework):
Frame the Problem (with data): "Over the last 18 months, our time-to-market for new features has increased by 200%, from an average of 2 weeks to 6 weeks. Our bug rate has also increased by 40% per release. This is because any small change requires a full system deployment, a process that takes 3 hours and has a 15% failure rate. This is directly impacting our ability to compete and is burning out our engineers."
-
Apply the Lenses to Build a Holistic Case:
- (Product Enablement): "By separating the User Profile service first, the Growth team can iterate on their onboarding experiments independently, without being blocked by the release schedule for the entire application. We estimate this will allow them to run 4x more experiments per quarter."
- (Risk Reduction): "Our current architecture means a bug in the non-critical recommendations engine can bring down the entire checkout process. Isolating services reduces our blast radius and improves site stability."
- (Efficiency Gain): "Smaller, independent services will reduce our build times from 45 minutes to under 5 minutes. This will return thousands of hours of productivity to the engineering team annually."
- (Strategic Positioning): "A modular architecture is the foundation for our long-term vision of offering our core logic as an API for enterprise partners, opening up a potential new revenue stream."
Propose a Phased, Low-Risk Plan: "We are not proposing a 'big bang' rewrite. We will start with one low-risk, high-impact service: User Profiles. This project will take one team of 4 engineers 8 weeks. The outcome will be a stable, independently deployable service and a reusable blueprint for future migrations. We will measure success by tracking the deployment frequency and bug rate for the Growth team."
This pitch is a world apart. It's a business case, not a science project. It identifies a clear pain point, quantifies the impact, connects the solution to multiple sources of value, and presents a pragmatic, iterative plan.
Conclusion: Your Influence is Your Greatest Tool
As you grow in your career, the scope of your impact will be defined less by the code you write and more by the change you can inspire. Your ability to see a problem, frame it in terms of business value, and build a coalition to solve it is what separates a senior engineer from a technical leader.
This framework is not a magic formula, but it is a starting point. Start practicing it on smaller initiatives. When you see a manual process that could be automated, don't just complain about it. Quantify the time it wastes and pitch a solution. When you see a risky dependency, don't just note it down. Frame it as an insurance policy and explain the cost of a potential failure.
By learning to look beyond the code and communicate the 'why' behind your work, you do more than just get your projects approved. You build trust, demonstrate leadership, and earn a seat at the table where the real strategic decisions are made.
About the Author
Hi, I'm Qudrat Ullah, an Engineering Lead with 10+ years building scalable systems across fintech, media, and enterprise. I write about Node.js, cloud infrastructure, AI, and engineering leadership.
Find me online: LinkedIn · qudratullah.net
If you found this useful, share it with a fellow engineer or drop your thoughts in the comments.
Originally published at www.qudratullah.net.
Top comments (0)