Framing the need well, doing cost-benefit analysis like your life depends on it…

Conflict. If you spent even just a couple of months in a cross-functional development team, you have most likely experienced it already. One of the usual sources of said conflict tends to be a misalignment between what product wants and what engineering wants. While the product manager is banging the table for more features, faster release cycles, engineers just as angrily voice their concerns about what's rightfully their prerogative — the state of the code, the infrastructure, the tooling, you name it. I find these conflicts interesting partly because neither sides is wrong per se, it's also evident that both sides care passionately about their own areas of expertise and goals, yet somehow, more often than not, end up rowing in two different boats in very different directions. I think it's time both sides learn to do better. But for that, both sides need to do some hard work and, more importantly, engineers need to learn how to ask for things.

The ultimate goal of a business is success. It's not the code you write, and not even the product you build. Amazing products can be unsuccessful, and great code can be irrelevant.

That said, if a business is to be successful, it can only be so if engineering and product find a path forward together and that's not an easy one to walk, as software, even the best built software — especially modern software — is brittle, no matter how bulletproof you build it. Us, software engineers often have to balance the needs of the business with the needs of the codebase, the infrastructure, tooling, and a myriad of other things. As teams are limited in size — and for good reasons — allocating resources to product development and engineering needs, like handling technical debt, can become a very tough challenge to solve. What I found over the years, however, is that the vast majority of times the challenge isn't in finding the resources or doing work, but rather how the engineering need is phrased and presented.

Most product folks I have worked with have never written a line of code, don't understand much about continuous integration, continuous delivery, pull-requests, code reviews, etc., and I have come to the conclusion that we can't expect them to, just like they don't expect software engineers to understand everything about being a product person. So, what do you do when two groups speak two different languages, but neither can be expected to learn the other's? You develop and use a third language, one that both groups speak — the language of success, which can take different forms depending on the conversation. But before that, some extra context.

A note on engineering-led companies

Speaking from lived experience, many engineering-led companies fail to ever make profit in a capitalist society where customers vote with their wallets. In fact, engineering-led companies can collapse an entire country's economy, and it all stems from engineers often not understanding what customers are willing to pay for.

Post-communist Romania learned very quickly just how irrelevant tech jargon and clever engineering approaches were in the context of a brave new world where they suddenly had to compete with Western products. From washing machines to TVs, cars, ovens and radios, suddenly nothing Romanian-engineered was selling. Technically, there was nothing wrong with the products. Heck, having learnt from the Soviets, even a basic cassette player was built like a tank. But, it sort of looked like one too. Built to last, but hideous, boring and outdated.

When engineers decide where a consumer-grade product goes next, you have a problem.

And Romania had a problem. Factories after factories closed because — among other reasons — engineers were deciding what the next product should be. Marketing was quite literally a foreign concept, so even the good decisions went unnoticed and sales had no idea how to sell something that only engineers understood the benefits of. Long story short, Romania's entire domestic engineering industry collapsed, and it has never recovered since.

Across the pond, another situation was brewing with a potentially very similar outcome. Just 7 years after the fall of the Berlin Wall and Soviet Empire, Apple was about to go bankrupt too. As much as I love Steve Wozniak, it wasn't him — the engineer — who brought Apple back to life, relevancy and finally, made it one of the most valuable companies in the world, but the other Steve, and if you look at Job's (and Tim's) Apple, you quickly understand Apple isn't an engineering organisation, it's a design company that just so happens to use engineering in their iconically designed products.

It's crucial to understand what drives success, and present engineering needs as a key component of that driver.

Traits of the common language between engineering and product

Which is why all engineers need to learn how to talk to product, or frankly anyone curious enough to ask why developing something costs X instead Y. Using the right language is far more important than many realise, and not just successful businesses but our entire modern civilisation is built on one person telling something to someone else in a comprehensive manner. Effective communication runs the world and has done so for millennia, and yes, that means from an engineer's perspective, things often have to be "dumbed down".

"Dumbing things down" is the single-most critical technique in effective communication.

I'll admit though that I don't quite appreciate the colloquialism itself. Dumbing things down implies the person we're talking to, is inferior to us, which, I think, is rarely the case. I see a "dumbed down" message as a clever translation that considers the interlocutor's context, not just my own.

Not so long ago, one of my product managers wanted to understand why refactoring some of the code was necessary. He was — and rightly so — worried that a task he imagined would take just a couple of days, was going to take two weeks. His words, not mine, to the team were "can you explain as if I were your grandmother?" I did just that, and it went like so:

Imagine having to go buy a loaf of bread from the shop just around the corner on the other street. Now imagine that you live in a cul-de-sac, so to get to the store, currently you'd have to walk to a bus stop, get to the next underground, travel 5 stops, to then get the tram which eventually will drop you off close to the shop you wanted to go to. You'd buy the bread, only to have to go through all that pain of travelling in reverse, and you'd have to do that every couple of days. What we're proposing with the refactor is to break the wall down from your cul-de-sac, extend the road so that you can just walk 5 minutes to the shop anytime you like. Yes, it's a bit of an investment upfront, but then every subsequent task would take very little time.

He enjoyed that explanation so much, he even reached out to me after the meeting to thank me for ensuring he understood the cost-benefit aspect of our engineering proposal. It became clear to him, we don't just want to refactor code because we don't like it, but rather to enable him and the team's velocity in the future. It's not dumbing things down. It's rather making sure everyone in the room understands the value of an engineering need.

But dumbing things down doesn't necessarily sell an engineering idea or need. Remember that we're dealing with a business that wants to make money, and not only because it's a business, but also because engineers like to get paid handsomely.

What seems to elude many software engineers is that we're very often hired with an implied understanding that our decisions will not run a company into the ground, but quite the opposite — will enable the business to grow. It is in every software engineer's best interest to learn how to make business-conscious engineering decisions. Hence, one of the best skills one can pick up over their career is the ability to present a good cost-benefit analysis.

You need to know how to make a business case for an engineering need.

No executive, or product manager will be moved — and frankly they shouldn't be — by hearing how tough it is to solve certain software engineering challenges. The company pays good money to many engineers, especially those from senior and above, not to solve easy problems, but to tackle the truly challenging aspects of software engineering. Easy jobs are not meant to pay 6-figure salaries. However, if you take that 6-figure salary and explain how your time and implicitly the cost of keeping you employed could be utilised far better by tackling a certain technical debt, a migration, a 3-party integration or heck, even an entire rebuild, people will start listening. Tie all that into business goals, actual dollar numbers, and you'll be presenting engineering strategies in the boardroom.

A few years ago, some of us from the frontend-teams realised we were facing several major issues. Our codebase was an entangled mess of Angular.js (yes, version 1) and React. The former was about to lose any kind of support — not even security updates — and the shoehorned React bundled inside of it was becoming an unstable, unmaintainable and unscalable heap of mess. But it was a 6-year-old codebase, and unfortunately, it was built during a tumultuous time in frontend technologies. Something had to be done. At this point, even our CI and CD pipelines became painfully slow — think a total of three hours to run all tests on all of our environments.

So a plan was formed to which many of us contributed. One of my colleagues sat down and researched monorepos, the other did a deep-dive into microfrontends, while I spent some time on analysing the amount of time us engineers were spending rebuilding the application every time we hit save in the IDE. My calculations alone resulted in a roughly 1 million dollars worth of wasted time every year. Even in a 1 billion dollar company, you tell someone you can save a million by spending 300K, and you'll be listened to.

So we put all the data together and the plan was presented in the boardroom in front of the VP of engineering, most of the product managers and anyone else who was curious. It was a packed room. We made sure of two things:

• Present the numbers. Not just for product and the business but everyone else in the room. It was crucial to drive home the cost and the impact as that later enabled putting together a team whose sole purpose was to solve this challenge in the agreed time and at the cost we predicted.
• Product managers and product owners were presented with a strategy that didn't just speak their language — we kept engineering jargon to the minimum — but also got them excited about the future. We even demoed some of the benefits we would gain by moving to microfrontends.

The excitement was palpable. My team's product owner, who was by no means a technical person, couldn't wait to see us build the future and burn the old code with fire.

The moral of the story is that numbers open pockets and stories about the future inspire people. The need is unchanged, but it's framed very differently. Prove the engineering problem is a product problem, and suddenly, you have a business problem searching for a solution. Suddenly, everyone wants to solve the problem.

If you can't translate it to a business problem, it's not a problem.

That may sound blunt, I know, but engineers need to understand that's how businesses stay in business. A business cannot go on a hiatus while us, engineers, refactor the entire codebase every 2–3 years. A business will not fund adopting a new framework just because it's the hot new kid on the block. Some might, but that's generally not the case. If that's what you're looking for, try a startup that still has too much money to burn.

In product, we trust?

Make no mistake, though. While you probably just spent 7 or so minutes reading how engineers need to learn to sell their needs within the context of the business, that's not to say the business — and I mostly mean product people here — don't bear just as much responsibility. Just like product should not implicitly accept everything engineers say, engineers should also ask product to prove their needs with numbers, especially because product, unlike many other departments in a company, are uniquely placed to earn trust through impact. Impact is measurable, and the numbers can tell whether the product team is on the right track or not.

Trusting product can't be implicit. Ask for the numbers.

In most Agile organisations, product's work ought to be done — ideally — based on customer data. You can't go ahead and develop features that aren't supported by customer data. Why spend a million dollars on something that no user has asked for, right? Now, because we don't live in an ideal world, it does happen far too often that engineers spend time on developing useless features that don't only fail to elevate the product and bring in more customers, but might even degrade and fail to retain existing users. I think, part of the blame falls on engineering for not asking for work to be justified with data, but equally on product for "throwing stuff at the wall and seeing what sticks" instead of doing the hard part of the job and creating research and data-based hypotheses on what they'd like engineering to work on.

Of course, that's not to say that basing the next feature off of some data or research will always result in success. In fact, the industry average for A/B testing software is around 3/10 successful tests. But one should constantly strive to learn as much as possible, even out of the failed tests. There is zero value in doing meaningless tests for the sake of keeping engineers busy.

Engineers should always ask what the expected business impact of their product development will be.

Let me make it clear. All of this isn't about lack of trust. It's about mutual accountability and respect. When both sides push each other for well-informed decisions that have a measurable impact on the business, the teams become more efficient. Everyone will spend less time on unnecessary distractions and the team will learn how to prioritise work in a way that it makes sense both for the team and the business.

Tips on how to sell…

Not to leave this purely theoretical, I thought I'd end it with a list of practical examples on how to sell engineering needs that I, personally, have been involved in over the years. Would love to hear other examples in the comments. In the meanwhile, without further ado:

• How to sell a platform/framework/language migration. Think, for instance, going serverless or breaking up a monolith into microservices. There's the implied migration cost, and then maintenance and operating cost. If you're providing a cost-benefit estimate to the business, you ought to make sure you're thinking long-term. Arguments like "because it's popular", or "it's cumbersome to work with" alone won't get you far. Typically, these migrations need to demonstrate a reduction of costs alongside potential other operating benefits like scalability, increased security, better UX and thus more satisfied customers. The same applies to migrating a language or framework. Just recently, I co-led and executed a Ruby to Java migration and in our case the reduction of maintenance effort alone was worth the migration cost.
• How to sell a code refactor. To put it succinctly, code that's rarely ever touched, likely doesn't need refactoring, so start by not suggesting a refactor in an area of the codebase with very little foot-fall. Typically, the best argument you can make for refactoring a piece of code is that it's a constant issue for the entire team, or more teams. If refactoring that code has a multiplier effect, even better, you should absolutely mention that. Even if ballpark numbers, you can calculate how much time and thus money you're saving by making the code easier to work with or more efficient to run.
• How to sell cleanup. Remember the adage "we'll clean it up later"? Sometimes all you need, is reminding the team how many times you said that and how many times it was actually done. The best way to do this, is by proactively creating tickets for every cleanup promise. It will inevitably pile up and start bothering someone to the point that it becomes embarrassing that the cleanup backlog is 10 times longer than the development backlog.
• How to sell building something in-house. We live in a world where software as a service is pretty common-place. That does not mean however that for everything your application does, it needs to call another 3-rd party service or use a 3-rd party library. That in itself is already problematic as you're introducing many dependencies you may have very little or no control over. Some may decide to go premium and ask for a license fee out of the blue, while others just bog your application down. Do you really need Moment.js in every app? Even its creators agree, you probably don't.
• How to sell adopting a 3-rd party solution. The reverse of the above is usually much easier to sell because it comes with all the standard benefits of not having to worry about one more thing, and pay incrementally for a service rather than cough up the investment and maintenance cost. That said, you still have to justify it with dollar numbers. Your calculations should demonstrate time-saving on the engineering side, freeing them up for more feature work while not exceeding existing costs. For instance, the frontend team I used to work with kept advocating for building our component library in-house, but the cost could not be justified to the product managers whose velocity would be severely affected, so we chose Material UI, slapped a theme on it and called it a day. The only real cost was certain design limitations, but both designers and product managers were happy to accept that and stay creative within the limitations of the library.
• How to sell accessibility compliance. Scare tactics. I wish I was joking, but I'm not. The vast majority of professionals in tech aren't concerned about accessibility, unless you bring up lawsuits, at which point they'll ask "how much is the fine?" trying to balance legal and reputational costs with design and development work. What will truly scare them though is the loss of revenue, so focus on that. Demonstrate how the business won't just lose potential new customers, but lose existing ones. Take for instance Ed-tech. If an application is not accessible, the entire state (talking both public and private K-12 education) might ban your product from being purchased by schools for an entire year. And you might think, there are plenty more states left, but what very often happens is one state follows the other. This is not an exaggeration, companies can get into serious financial trouble for not meeting accessibility guidelines. Show them all the dollar numbers preceded by a big fat minus, and you got their attention.

Each of these could of course very well be an article in itself, or an entire chapter in a book, but the heavily abridged versions should still point you in the right direction.

Finally, I should mention, exceptions to all of this exist. I'm sure we all have plenty of stories where we couldn't get the message across and an engineering need got ignored until it turned into a disaster. It happens far more often than it should, but experience tells me, us — engineers — could have often done a better job explaining why sometimes engineering work takes priority over product development.

Attila Vago — Software Engineer improving the world one line of code at a time. Cool nerd since forever, writer of codes, blogs and books. Author. Web accessibility advocate, LEGO fan, vinyl record collector. Loves craft beer! Read my Hello story here! Subscribe for more stories about LEGO, tech, coding and accessibility! For my less regular readers, I also write about random bits and writing.