Engineers Don’t Just Write Code
Most engineers have, at some point, wanted to fix something that isn't a feature. Paying down tech debt, adding tests, improving build times, or migrating to a new tool—these are all investments that feel critical to the people who write the software. Yet they rarely show up in sprint planning. Product managers tend to focus on capabilities and customer requests, and platform deficiencies can start to look like "just the way it is."
Before you can convince anyone to let you take on that work, you need to reframe your own role. You are not a software engineer who codes. You are a human with coding skills who was hired to push the company's mission forward. If the company is functional and you're aligned with its mission, the conversation stops being about "my work" versus "their work." It becomes about which work has the better benefit-to-effort ratio, within a relevant time horizon, grounded in that mission.
Comparison Is the First Step
Before you bring anything up, do the honest analysis. Take the top feature you're supposed to work on right now and weigh it against the top investment you want to make. Compare benefit-to-effort ratios, but don't forget to factor in long-term impact and compounding effects. Also keep in mind the company's mortality: you need to stay in business long enough to realize the benefits.
If you don't have enough information to evaluate the features the product manager is prioritizing, go ask. Ask questions about how those features tie into the mission. Keep an open mind and a genuine desire to understand. The analysis might conclude that your investment is not the right thing right now, and that has to be an okay outcome.
You can't compare what you don't understand, and you can't make a case that's grounded in the mission if you don't know how the other work is grounded in it.
Make the Problem Theirs
Once you're convinced your investment has a higher long-term benefit-to-effort ratio than what the product manager is bringing you, it's time to talk. The conversation should not be a surprise. Keep the product manager aware of the investments you're considering and let them know you're analyzing the value those investments have for the mission. When you do come to talk, you're simply reporting the results of that analysis.
Your job in that conversation is to help them understand that your investment is mission-critical. Start with the problem—not the solution. If the decision maker doesn't have a clear understanding of the problem, it doesn't matter how good the solution is. The problem needs to be the their problem. It must be related to the mission, and you need to communicate what it costs to do nothing about it in the long term.
Once they grasp the problem, then you can introduce the solution. Make sure they understand the effort involved. They are going to run the same benefit-to-effort analysis you did when they prioritize work, so give them all the information they need to come to the right conclusion.
Trust the Decision Maker
The company hired a product manager to prioritize work in the way that best pushes the mission forward. If you've communicated your analysis effectively, you've done what you can. Trust that they may have context you're missing.
If you experience cognitive dissonance at their decision, then there's been a misunderstanding. Either you misunderstand the problem or solution you presented, you misunderstand the importance of the work they prioritized, or they misunderstood you.
That's a job for an honest, good-faith discussion. Express your thoughts and ask them to help you understand their perspective. You might gain new insight and become comfortable with the decision. Or you might uncover a misunderstanding on their side and get a better outcome for your idea.
When the Mission Is Wrong for You
If the company is dysfunctional, or you don't actually align with its mission, the math changes. For a dysfunctional company, try to find out what truly motivates the decision makers and make sure they see the connection between what you want to do and that motivation. Unstated missions that revolve around politics and internal games can shift or get hidden. If that's the culture, expect unpredictable roadblocks and start looking for a better place to work.
There's also a scenario where the company is good and the mission is fine, but your personal goals and the mission are misaligned. That's exactly what happened to me when I was working at Alianza. I was getting frustrated with Angular.js and noticed Angular 2 wasn't really an upgrade—it was another migration to an entirely new framework. Since a migration was inevitable either way, I preferred React. I brought it up with the decision maker, but he said there was no budget for a migration. We were a small frontend team and the benefit-to-effort ratio didn't make sense within that time horizon.
It wasn't a surprise, and it also wasn't a poorly run company. They had funded plenty of platform investments. It just genuinely didn't make sense for the business. But my personal career goals involved moving from the Angular community to the React community, and that tradeoff meant I started looking for a new job. The company was right to say no; I was right to want something different.
Alignment Through Communication
Business and engineering alignment only works when both sides are truly focused on furthering the same mission. Once that's true, alignment becomes a matter of proper communication, mutual respect, and understanding. Convince yourself first that your idea has the right benefit-to-effort ratio, grounded in the mission. Then convincingly communicate that case to the people who prioritize your work.
You need to determine and communicate the benefit-to-effort ratio within a relevant time-horizon that is grounded in the company mission.
