Hint: It has nothing to do with your technical skill
The key to your company seeing you as valuable is not what you think.
It’s common for software engineers to misunderstand the value of the work they produce. To some, the actual code is seen as more valuable than what the code does. As engineers, we tend to bury ourselves in acronyms and technical minutia but fail to understand why and what we’re building. Using specific tools becomes the goal rather than delivered business value.
These misconceptions relegate engineers to but a cog in the wheel. Business people begin to speak in terms of resources, heads, level of effort, and hours. No other divisions in the company get associated with these insulting terms, yet engineers become the lesser species. Finance wants to know how much. Sales want to know when. Operations want to work out where you fit in their flow chart. And what about the product owner? They want to tell you how to do your job then swing a gavel when things go wrong.
It’s a sad existence, but engineers shoot themselves in the foot — daily. They bow out of value-based conversations. For some reason, engineers will accept any crap anyone asks them to build. It’s as if there’s a military hierarchy, and engineers are the troops.
I love coding too. But understanding when you code and the reasons behind the code are great liberators. This knowledge frees you from the day laborer mentality that plagues the software development industry. Ever notice that every software development lifecycle process treats engineers like they’re making chocolates? It’s an assembly line of BS that encourages people to talk about the process more than business outcomes.
If I had three wishes, one of them would be for engineers to understand their value. I’d want them to recognize that they deserve an equal seat at the decision table. I often feel unglued in management-level meetings listening to questions. I listen to questions like how many more engineers do we need? Or, what do we need to do to get more out of the team? I often think: I don’t know, how many salespeople do you need to sell what we have?
The point is: each business division should be on equal footing. Engineers need to understand how the business works. To be respected, you must demand it. And until we stop saluting and blindly doing what we’re told, we will continue to be whipped like a mule with little to no work-life balance.
There’s no doubt that some engineers will continue to bury their heads in the sand. They will spend a career doing what they’re told. But for those who want to buck the trend, here are a few secrets I’ve learned from people smarter than me.
You can’t expect to know your value if you don’t know how the business makes money. I’ve been blown away over the years with the sheer number of engineers that have no idea how they get paid. If they’re at a product company, they don’t know the value proposition. If they work at service companies, they’ve spent no time understanding what salespeople say to sell their talents.
You can assess your value by understanding sales. Value is a measure of impact, not always counted with numbers. As an engineer, you’re a valued member of the organization. Sure, a salesperson has responsibility for selling your company’s gems, but there’s no excuse for not understanding how money flows within the company. The best way to assess your value is to know how your work contributes to financial success. I mean: should you be paid $80K but contribute to millions of dollars of value? Not everyone can have that debate with the business but think about it.
If you want to be a rockstar, spend time learning business lingo. Does your work help reduce customer churn? Are you increasing customer confidence? The reason you’re scaling the backend infrastructure is to reach more customers or improve performance. If nothing else, if you understand why, you solidify your seat at the table. You increase your value while other engineers debate technical jargon.
You can hit 100% of your deliverables and fail.
Who cares about sprint cadence and the number of hours a project took if no one buys it? I see engineers as master builders, not extended hands that take orders. At every level, there’s an opportunity to ask thoughtful, insightful questions that help you make your own assessment of a feature’s value.
The key question is: what’s the achievement? How are you improving the condition of the software, customer, and subsystem? Beyond the deliverable date, what sentence would you write to describe increased value? The best approach is to take a moment and assess value yourself.
Your React Native analytics dashboard has business value. The hours that you spent designing Kubernetes clusters improve the quality of the business. Your task is to understand how and describe it in layperson’s terms.
Understanding how you improve business outcomes requires a shift in thinking. Here are a few tips:
- Describe your task in regular words, then add “so that” at the end. Challenge yourself to understand the why behind your valuable work.
- Ask yourself what happens if you don’t do the work you’re responsible for? Better yet: ask whoever assigned the work to you.
- Figure out how the condition of the software improves. How does the user of the product benefit? What does a human get in the end?
- Think about the personal gain of your colleagues. If it’s a salesperson who is the business stakeholder, ask them why it matters to them? Doing this will allow you to speak their language immediately.
Some will read the above and assume that it’s not the engineer’s job. You may feel it’s not your place, but you’d be wrong. Getting involved beyond zeroes and ones will increase your value ten-fold.
A picture is worth a thousand words.
With many tools out there, it’s not too much work to draw pictures that help explain things. Architectural diagrams demonstrate how you improved the quality of the subsystems. Flow charts help describes how data flows. By creating artifacts, you improve everyone’s understanding, and you increase transparency.
A funny thing happens when you try to draw what you’ve created. It forces you to rethink what you’ve built. When you have to explain it to someone else, it requires you to have a crystal clear picture of how things hang together. A good practice is to look at the work of other engineers and develop your own style. There’s nothing more powerful than a show and tell with a business stakeholder. If you involve them, and they see you as more than just a coder.
Showing interest in other people is a secret weapon.
The power of a simple human conversation moves mountains. I get how this one can be intimidating. Talking to so-called sales or executive people can be daunting. They can seem like aliens. But if you take the chance and ask them about their responsibilities, they’ll open up.
Your only risk is learning more about the business. The next worst thing is, you end up having a voice. Becoming an influencer is a powerful force with untapped energy.