What Software Engineers Really Value in a Job: a Bottom-up Approach

By Rafael Martins

If you’ve read about what tech leads and CTOs have to say of what software engineers really value in their job, perhaps now it’s time to meet an honest perspective from a software engineer himself.

As society changes from a WFO (work from the office) era to a WFH (work from home) one, how we manage people has also changed. Or at least it should have.

Financial markets are pressuring companies to handle this challenge fast, precisely, before it’s too late.

In this article we’ll talk about leadership, but not following the usual top-down approach, as in other articles already published in our blog:

Through a bottom-up vision, by following a divide and conquer approach, we’ll focus on one of the most important assets an IT company holds, its engineers.

Engineers, as their teams, are an indispensable piece of this engine we call a company. Understanding their needs and how we should manage them will likewise endorse your business. Doing so will eventually attract new people to it.

Happiness, the feeling of positivity, really is the foundation of productivity.

– Miguel McKelvey

What is an Engineer Looking for?

As software engineers, we are lucky the market is currently favoring us. As more and more companies invest in their technical stack, like websites, internal products, or related items, the current workforce is not enough to cover all those needs.

Having that in mind, we can be pickier about what we want. Otherwise, having an interview and accepting a new offer might only take two weeks.

Engineer retention is one of the main topics with which some companies struggle the most. We all know that losing someone to another company and onboarding a new one has its costs (what’s the real cost of losing an employee? check it in this article), and if we want to focus on developing the business, we must avoid having to interview, screening candidates, and onboarding new hires every couple weeks.

From an engineer’s point of view, these are some of the main goals we strive for after accepting an offer.

Salary

I know… Everyone wants to earn more and more!

An engineer is no exception! We constantly complain about how bad our salary is to our fellow engineers, despite how good we receive compared to other roles.

Where one struggles the most is when we see no progression after all. When a company has no role tier level system, or in other words, a role level progression system aligned with a new salary.

Why would one want to improve his skills if it would lead them to the same financial place? We all know that knowledge is power and that money shouldn’t be the main factor guiding us to learn and become more. But by the end of the day, being financially compensated by an increased salary or bonus will be a significant factor being considered by an engineer whenever choosing to move on.

A role tier level is always aligned with a given salary through several feedbacks during the many company’s quarters. As the engineer gets placed on a given tier, it will show progression over his career and finance.

We can describe it as a kind of gamification system, the more and the better you do, the more you will get by the end.

Who doesn’t want to earn more money?!

Interesting and Challenging Projects

It is easy to dread Mondays if you dislike what you do. From an engineering point of view, disliking the current project might be related to several separate topics from:

Tech Stack → Old languages, deprecated frameworks, or it could even be a super recent stack but not aligned with an engineer career goals.

Just another one → I used to work for the insurance sector, where most of the projects we took were for client self use, mostly migration projects. Even though the tech stack was interesting, the flow was always the same. Migrate business logic from A to B, expose it, mitigate issues if any showed up.

Money VS Strategy → By the end of the day, it is all about business. More and more revenue will always be the top one priority, whatever you say. However, companies need to consider two factors, the revenue a given project will generate as the controlled happiness of the correspondent implementers. Is it worth having leverage on one over the other?
We should adapt, not the client → In past projects, project development was always performed alongside the client. We had our retrospective sessions with them, other sessions which they would use to raise issues to be solved on the way, as well as approve any expected planning for the future.

However, when the client demonstrates difficulty in how to behave or goes against our way of doing things, we should be the ones raising the red flag. We shouldn’t expect to have a client who knows how we operate or to comply with our standards immediately. We should be the ones teaching them.

Unfortunately, I have seen and experienced many projects where these red flags don’t get raised, forcing the team to comply with their “expertise” approach. Most likely leading the project to an unorganized state.

We all know where these end, right?

Lack of Resources

It sounds reasonable to supply the required resources to an engineer for their duties, right? The real world isn’t that reasonable. Unfortunately, you might not believe it, but only in my third company, I finally managed to get supplied with everything I needed to get the most out of my skills.

By everything, I mean a proper laptop that doesn’t take ages to answer and an engineer-friendly infrastructure that allows you to avoid doing a marathon to reach your goals.

I needed to push the board and sysadmin team several times, so they could merely understand how much they were losing by not letting people get the most out of their skills.

Shouldn’t it be a win-win situation?!

Team Spirit

Stick with me when I say these are real struggles that I and a lot of well-known engineer fellows felt throughout their careers.

The one that made me feel truly sad, and doubt if I was in the right place, was working with people who didn’t feel the need to become better engineers.

Why learn new skills if our current ones do the job?
Why give feedback about what went wrong during the development phase if I only need to care about my work?
Why should I suggest any improvement if nobody cares?
Why should I follow the suggested conventions if I like mine?

A lot of whys, but unfortunately, no action. At first glance, we might think that’s their problem, although I believe that changing this mindset it’s everyone’s responsibility.

The hiring team should filter which people fit the best for their needs and culture. Anyone beyond or below it’s already a red flag that will eventually arise.
The product owner should impose the expected team mindset from the beginning. When new people get introduced to the project, or people that were there but in the meantime forgot their team principles, refresh their mindset.
The architect should always keep pushing the project quality’s standards, pushing for suggestions, constant reviews on the current development flow, and an initiative mindset.
Colleagues should keep helping out their coworkers by pushing into new paths and new career progressions.

By not enforcing our culture from the first moment, we’ll lose employees to someone who does it eventually.

Training

Whenever you have an employer who cares about supplying a budget or internal sessions to teach about technical topics frequently, it means they are investing in the long term.

As we work in IT, we can quickly notice how fast this sector evolves, and delaying learning new skills might be enough to lose the train fast. Giving the required tools for someone to grow will endorse your business quality as the engineer skills. Undoubtedly a win-win situation.

Transparency

How can a small word have such a significant impact on people?! Thankfully in past companies, I have been close to board members who usually have an impactful word on which path the company will follow.

As an engineer, topics such as salaries, equipment, and career path are a big deal. Sometimes I was caught in the middle of decisions that no one had a concrete explanation for. Where answers seem to be running away from the truth.

Sometimes such answers only create doubt about how much trust I should place in the company. Is it only a company or a family that some might say?

The Balance We Should be Looking to Reach

In a company, we should always be looking for a balance. Usually, the more you give to people, the more they will ask in the future. However, the other way around doesn’t work quite well, the less you give to people, the more they will ask, and more will eventually leave.

Each topic discussed in the above section has its own relevant space within the decision-maker between a job offer and your current company. Having that in mind, promoting some of those may be a very good idea.

We know that some are easier than others. Probably we might be in a place where increasing the salary is out of scope due to current debt, but making sure an engineer is placed in an environment that favors learning, teaching, and trying new things may be easier.

But again, transparency may overcome that feeling that nothing will change, that no one cares. Open communication will always be a game-change benefit a company can have, so please speak out for your people. Don’t forget that if they are in this rocketship with you, it’s because they believe in your vision. So help them make sure that they still have the right beliefs.

What Software Engineers Really Value in a Job – Final Toughts

I hope this article was insightful enough to the point of making you realize that retention is possible and desirable for both the employer and the employees.

If you’re a team lead or a CTO, then you’re in the position of changing your company path, and I hope this article will inspire you to do so.

I’m a simple engineer who has experienced each of the mentioned topics and knows a few people who have experienced the same – the value of it? A bottom-up vision that can illustrate your team’s thoughts and feelings about their work experience, that hopefully you can use to improve your retention strategies.

Remember that by the end of the day, we – the software engineers – only want to feel included, cared for, and excited to face the challenges awaiting us the next day!