As developers, working toward better positions and better salary means increasing your worth to your employer. Getting better at the technologies you use is a given — we should all be doing that. But past that, it gets a bit murky. How do we tangibly increase our value to the companies we work for?
One great way is learning how to impact the business side of things in addition to the technology side. I’ve seen this a lot lately as developers and other teams continue to fight for a “seat at the table.”
Take this article on UX trends, for example:
“We have to be able to talk to our business peers about lead generation, CRM, metrics, EBITDA, targeting, retargeting, revenue models, search engine marketing, direct response landing pages. Even more than that, we have to know when and where to put on business hats ourselves.”
Or this one, talking about developers specifically:
“[Businesses] don’t just want good coders. They need good people who can code at the same time as understanding the real-life application of what they are doing. Business-savvy, young, bright developers are very valuable.”
“Software engineers can no longer rely solely on their technology expertise, but they also must have a keen understanding of the strategic impact of technology decisions on the business.
“In the midst of a software engineer shortage, the scarcity of business savvy software professionals who possess both leadership and advanced technical skills is particularly pressing.”
I sense a pattern.
We’re all learning the same principle: our work doesn’t happen in a vacuum anymore. Developers can contribute a lot of unique and valuable insights to the discussion, and that’s a great way to increase your worth as an employee.
This can feel like foreign territory for many developers, but it’s actually quite simple. A change in mindset and a few basic principles can get you started down this path without much cost to you. Specifically, learning how to speak the language of business, how to sell, and how to increase efficiency can go a long way in making you much more valuable as a developer. Let’s take a look.
It’s often said that developers and the rest of the business speak different languages.
There’s some truth to that.
Developers, on a daily basis, tackle complex issues like scalability, reusability, clarity, calculated risks, and many more. Business primarily speaks in two dialects: time and money. Don’t get me wrong — these things can be very complex and are absolutely vital, they are not simple things. There are different things that affect this, of course, like quality and relationships — but to really get the attention of the business, time and money are what you want to talk about.
Now, I can already hear some of you saying: “Wait a minute! Developers think of those things all the time!”
And that’s true too.
We think about sustainable architecture, reusable code, and effective third-party solutions quite often, and those translate to time and money. Just like almost anything you can say in English has a good Spanish translation, developers end up talking about time and money quite a bit, but we usually don’t deliver that translation. We don’t do it in language that the business can relate to.
Let’s say a project team is demanding that you do a rush job on a new feature. It’s technically possible to get the feature done on their timeline, but the resulting code will be unwieldy: it won’t be reusable, it will make future updates slower, and it increases the likelihood of bugs on that page.
“That’s spaghetti code! We’re going to have to work around that code every time we touch the page, and that’s all wasted time if we need to do this again!”
All valid points, but it’s in the wrong language.
This might work better:
“We can do this, but anytime we touch this page, it’s going to be a 10% increase in development and QA time. Also, if we do this again, the development time doubles. Are you comfortable with that?”
That’s the language of business. If you can’t do math with it, it needs a translation. Now, it typically goes one of three ways:
In case you missed that, I’ll reiterate: This is not some Jedi mind trick to win arguments every time — learning the language enables you to more effectively communicate about these types of issues. It’s not always about your solution, it’s about the best solution, and sometimes you can’t arrive at that until after some conversations and compromises.
Just about any developer knows that it can take time and money to do things right. For instance, spending a little extra time working with the designer can result in a much more manageable solution that’s easier to implement. But suggestions along those lines aren’t always heeded.
Why? Again, a little translation might be in order.
Case in point: cost-saving third-party solutions. Finding third-party solutions that already do what the project needs are great cost-saving tools, but they need to be communicated as such.
If it costs $500 for a commercial license, don’t say, “Can we have $500 for a commercial license for this helpful tool?”
We’re not asking if we can spend money — we’re asking if we can save money.
Say this instead: “Having this tool will save us 16 hours of development time. It’s a paid license, but we can bill that to the project and still net out ahead.”
This change is definitely more evolution than revolution. You don’t have to go to business school to get this done right, you just need to give a rough estimate of the cost of their change, and hold them to updating the budget or timeline if necessary. This is the most basic thing in this article. It’s not hard to make this adjustment and some are already doing it — but this is also foundational to everything else here. So remember: the foundation of impacting business is affecting time and money.
Learning to sell is something that can easily set you apart as a developer — not many developers know how to do it, and even fewer are willing to try. This often leaves selling to sales and marketing people who are significantly less knowledgeable with the technologies we use and what value we have to offer clients. This isn’t to say that every developer needs to be a full-time salesman, but the fact is, if you talk to clients — or even the people who talk to clients — you will eventually be put into a situation where you can sell a better solution than the sales team. These are times when you can really shine, and you’ll usually end up with a better solution to work with.
Selling isn’t always the most intuitive thing for developers because of that language barrier described above. Imagine taking your car in for an oil change. The technician asks if you want to spend $50 more to use a new, experimental oil.
“What does that buy me?” you ask.
“It’s a new oil,” he says. “That’s the direction the oil-changing industry is moving. It makes use of the newest Mudkip technology. We need to keep on top of that or we’ll fall behind.”
“Yes, but why is it better? Why would I pay $50 more for it?”
“It’s just better. Are you really alright with pre-Mudkip performance? Do you want to fall behind?”
Which would you choose? Yeah, I’d go with the cheap one too.
Maddening, yes, but I see developers do this all the time when explaining their ideas and solutions to clients and stakeholders. In most cases, technologies (and features) don’t sell — solutions do.
In the example above, the sale is not explicitly tied to a problem you have. It could be that the new oil will make things much better for you, but how would you know? And, perhaps the bigger misstep: the technician never took the time to understand your problems. There can be no solution if there’s no clearly defined problem.
Noah Kagan, founder of AppSumo, once said, “Find a service and build software for it. Do not build software and try to push it to a service.” Problems have to come before solutions or you greatly reduce your ability to sell anything.
The first part of selling is to determine the problem — and make sure the client or stakeholder knows you understand it. Ask questions about why they’re requesting the project. Most of the time, they had some very specific problems in mind. But remember, they’re not used to dealing with developers who help them solve problems, so they probably come to you with a solution, not a problem. Work backwards to figure out the problem, and then say it out loud to make sure they know that you understand it: “It sounds like the main problem is [x]. Is that correct?” This usually comes as a relief to them.
Once you have an agreed-upon problem, take a look at the solution. Maybe what they proposed is a great solution; maybe it’s not. If what they suggested is good, let them know. They’ll feel a lot more confident in you as a developer and will probably ask for your input later. If what they suggested is not a great solution, you have a major opportunity to save them time and money.
Phrasing is important. Again, don’t talk about technologies — yet. Keep the focus on solutions.
Don’t say, “Have you thought about [x technology]?” You’ll lose them.
Say something like: “If the problem is it’s taking too long for your team to update the site, there are better solutions to address that problem. In my experience, this CMS is the easiest for non-technical people to jump in and start using right away, and it’ll save us time in development too. Does that solution work?”
Marketing folks — people like your clients and internal stakeholders — are used to being problem-solvers for their companies. That’s a lot of pressure. Having someone throw technologies at them doesn’t make them feel more confident, but having a problem-solving partner does. Making sure they know that you understand their problems and are working on solving them is the most effective sales tactic a developer can use, and both the clients and the sales team will thank you for using it.
When I was first getting started in dev, I worked for a company that was extremely focused on cutting costs. Employees and managers were praised and sometimes promoted when they brought ideas to the table to reduce the time and money we had to spend to get things done.
This culture soon imploded and things got out of hand.
Teams were lauded for efficiency gains that mostly consisted of pushing your team’s work off onto another team. That team became overwhelmed and had to figure out how to push some of their work onto another team. Upper management thought it was great how much “innovation” was going on, but it was killing the company.
There were two problems there. One, there was no camaraderie amongst the teams — each team just looked out for its own, and inter-team conflicts sometimes got vicious. Two, there was no net gain — in fact, there was often a net loss, as teams had to adjust to getting new and unfamiliar work done and constantly-shifting responsibilities made things difficult to adjust to for employees.
Both problems illustrate the same point: efficiency needs to be measured across the whole company, not just your team.
At another company a few years back, I worked out some significant gains for the creative department. They were making Photoshop comps for pages that Photoshop wasn’t really built for: contact forms, admin panels, that sort of thing.
How long does it take you to build a good-looking form? Probably not very long.
How long does it take a designer to design one? Probably quite a bit longer.
How long does it take you to build completely custom form elements because the designer didn’t know which enhancements were simple and which were painstaking?
Way longer than it should.
When the designer got the shell of a website done and got to the contact form or admin panel, I would take over and take a stab at it. When I built something that looked pretty good, the designer would come over and we’d work together to tweak it. If the designer requested something small that would be a big change, they’d find out right there and usually changed their request to something easier. They even got some new ideas when I suggested simple CSS enhancements. I ended up spending a little more time than usual on the project, yes, but the overall timeline went way down, saving us and the client time and money.
Now, this only worked because both the designer and I were willing to sacrifice some time to help the other. I tried this on another project where the designer took a note from my old company and just wanted to unload all the unpleasant tasks onto me to save himself time. If that starts happening, stop — it’s not productive. But I’ve found that most people from other teams are happy to collaborate if it means saving the project some time overall.
Thinking about how to save other teams time and money is good on a small-scale, but even better on a large-scale. If something works well on a project, ask yourself if it could scale to work on all projects. Developers aren’t usually in the business of defining processes, and it’s a shame because we’re excellent problem-solvers and offer a much different perspective on projects than project managers or upper management. Like sales, this doesn’t have to be something you do all the time — after all, we’re developers first — but if you notice the same problems popping up on every project and have a good idea to solve that, sharing that benefits everybody.
These are some foundational principles that can get you started on impacting business as a front-end developer. There are many more, including subsets of each of these principles. What do you do, then? Do you memorize them all? Do you make flowcharts?
I’ve found that the best way to get good at these principles is to practice empathy, for both your clients and your coworkers.
Saving time and money is usually the biggest problem your coworkers and clients face; clients need partners who care about their problems and work with them to solve them; your coworkers may need your help and expertise on saving time and money in their own workflows. Each of these starts with just giving a damn about what they’re dealing with.
It’s true that some people are more naturally geared toward empathy than others, and that’s fine — but just about everyone can choose to practice it a little more. And choosing to practice it more is often the quickest way to get better at solving business problems for your coworkers and clients. When someone brings a request to you, ask what they really want, and ask why they care. Having the answers to these questions puts you in a much better spot to make a huge impact on that project and the business overall.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
Vibe coding makes building apps faster, but speed without engineering can create serious failures. Here are five real-world examples and practical checks to help you ship AI-generated code safely.
Compare React ViewTransition and Motion across four animation patterns. The native build saved ~38.6kB of gzipped JS, but required 179 more lines of CSS.
Learn how to run Cline locally with Ollama to build a secure, private AI coding agent that keeps your proprietary code off cloud servers.
Compare TanStack Charts, Recharts, and Chart.js by building the same React dashboard three times. See how each library’s mental model affects your code.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
