To begin with, there are few things to clarify. First, I'm just a developer myself. I'm not a manager, not a head of engineering, product owner or tech lead. I'm just a developer, and that's how I see myself growing. Second, this article is not about your technical skills, but I would address it to the Middle - Senior level. At the same time, I would love to hear opinions from less or more experienced people as well. Third, I believe there is a clear rule that you get as much as you spend on your development.
You love your company and feel that you deserve to be paid more
We, as developers, live in a very comfortable situation. The software development market is so huge, that there is a constant need in our skills. There aren't many spheres of work where you can find a job that easy, where you can switch companies whenever you feel it's time to go. This constant need in the best resources available makes businesses to create a good culture inside and outside the company, to keep existing developers happy while growing and attracting new ones. Hence, I truly believe there is no way that the company you like and work for is going to pay or value you less if your skillset enables the company to grow.
So what can you do to be the one getting the promotion with ease?
Find motivation
Not for yourself (you're internally driven, aren't you?), but for your team. Try to understand through discussions the main goal you, as a team, want to achieve. What are you working for? Is it a great product? Or you like to work with each other? Maybe it's opportunities you have to learn and develop your skills? Or is it the work-life balance you have? Each of the reasons is the valid one. If you don't learn enough, then why? How can you improve it as a team? Maybe the balance isn't there, then why? How would it be possible to get the right balance or motivate the team to get over a temporary situation? Raising these questions can be quite challenging, at least morally, as in the companies people usually afraid of saying what bothers them. There are many reasons for that, including "If others are fine, why should I complain? I don't wanna look like the one who complains a lot!". Talk about your motivation, find the most motivating and demotivating points and try to solve identified issues. I believe, that it all starts from the motivation: your team performance, hence the success of the product, and as a result satisfaction with your work. And from the managerial perspective, it's pretty hard to find issues if everyone just daily, ordinary and silently does the job. When you initiate the changes, it can't be unnoticed.
Start listening
During Agile ceremonies, kitchen talks or in the company chat. Try to notice pain points your product, organisation, or processes have. Discuss identified ones with other people to get some opinions. Then you can discuss the issues with possible solutions on your team meetings. In the worst-case scenario when the problem is not valid, or the proposed solution isn't great, you are the one who wasn't afraid to step in and say what worries you and (as you found out) others. I'll give you quick ideas:
- PR review takes too much time because of constant delays in communications - install GitHub bot to your company messenger no notify about PR changes?
- code formatting constantly changes - introduce formatting on a pre-commit hook?
- little knowledge sharing within the company and offices - introduce online teams hub/channel with all the resources and technologies each team uses?
- etc...
There are always problems to solve. Be the one who initiated it
Start thinking about the product
Some may argue that it's not always possible to come up with some bright ideas, especially in big companies, where many people work hard to identify and validate user needs. But nothing stops you from thinking about the user who uses your code. It is easier for Front End or mobile developers to have discussions with the designer about the end-user experience. For example: "This error page we show to the user can be replaced with some message, keeping the user on the page and allowing to try the same thing again or find what is wrong themselves. Or maybe we can show the page after the second attempt? Should the user click themselves, or we can try to attempt ourselves after some time?".
At the same time, I've seen many times backend developers bringing valid questions. For example, when they try out how their API is used and finding the issues just being a user of the product. Being in the core of the product or by working on the development infrastructure, engineers can bring a totally new perspective on the product they actually know a lot about. It can happen, and quite often, that product managers or designers just aren't aware of what can be done (same way they might think that something can be done). By understanding the main goal of the feature you build, the motivation behind it, you may suggest changes that nobody else just didn't think of.
Be a person to ask
The simplest way to put it is "be a leader". But I notice that people tend to get it a little bit wrong. In my mind, the best leader is almost unnoticed due to the whole team doing an amazing job. Yes, some people can stand out due to their nature. But what makes them stand out? What if this something can be inherited by others so that the whole team now has this "feature"? Is it knowledge about the application architecture? Then it's the duty of the leader to make sure that everyone knows how it works and how to make it better. Is it just experience? Well, others may not have it, but even the most experienced developers still learn, no decisions should be made by one person. Being a leader means to make other people grow with you, by motivating, providing assistance and directing them. Don't be afraid of being the one who points out to the issues, sharing your learnings and resources you use to learn. Be the one who spreads the knowledge from one specific person in your team to the rest of the team. If it happened to you that you asked multiple people about something before you found the answer - share this answer to the people you asked before, or with all of your team. Quick heads up in the team's chat will make a difference in the long run.
If you struggle to show off your knowledge, because of imposter syndrome - I feel you. It's a constant fight we have to deal with in our social world. I would highlight constant. But we can handle that. Here are the resources that helped me a lot:
Otherwise...
If you feel that your management doesn't follow your development and it's hard for you to get higher wages, easily look for other options outside the company. It's a clear rule that you deserve what you deserve and it's up to you to find out what you deserve through job interviews. And we will discuss it in the second part, as I need to get feedback about this article first so that the next one will be better! So leave your comments and links to the articles that can help people with developing any of these skills.
I also wanted to promote this video, as it was quite eye-opening and motivating for me:
What do we stand for? (Kind-hearted, Humble, Together)
Top comments (1)
Your advice is solid, however you presume that good developer === higher pay, but often this is not the case. A lot of times, a decent data scientist will outearn a good web developer, simply because data science jobs usually pay more. Plus, you don't take into consideration soft skills such as the art of negotiation, jumping on opportunities and having dumb luck.
By being a good developer you are in a better position to be paid higher - but in our field, where salaries are high anyway, is more money the end goal? Is it the epitome of our strive to be the better?
I think working on interesting projects, with good people and having pleasure doing what you do should be our goal, all while getting proper pay of course.