Most of the software developers who we talk to during the hiring interviews are looking for jobs while already having one. I always ask what’s the main reason for switching jobs and why they consider our company as the next place to work at.
Everyone has their own reasons, but the main things that people are looking for that I hear again and are:
- Ability to work remotely
- Strong engineering culture
- Open communication and transparency
- A sense of autonomy and ownership
The Challenges Developers Face
Yeah, the life of a software developer is far from perfect a lot of the times. You spend 2–3 hours on commute from home where you spend a lot of time at the screens of your device to the office where you do the same.
You have to work with outdated collaboration systems, technologies and devices because that’s the company policy. You feel like a cog in a large machine focusing only one task at a time not knowing why you need to do it and with no way to affect management decisions.
And finally, sometimes you don’t even feel like what you’re doing that matters — especially in the big teams, individual effort and ownership is replaced with group ownership. When everybody is the owner no one is.
It happens in all sorts of companies, both big and small. With a situation like that on a job market selling developers on working with us becomes quite easy. If you’re looking to build or expand your team, here are few things we focus on to make our company stand out and attract the best talent that you can use.
Offer Remote Work Arrangements
There’s a lot of debate about remote work nowadays — during COVID everyone went remote because there was no other option, but there’s a lot of pushback now. I’ve been working remotely all my professional life (that’s 20+ years), my company has 100% remote from day one (that’s almost 8 years), so for us this is natural.
It’s not hard to set up the remote work environment and honestly, it’s not very different from the office setup. The only difference with working in the office is the ability to have in-person meetings with the team and physically see each other, some watercooler time and occasional lunches and dinners with the team. Oh, and proverbial ability to walk to someone’s desk that managers love and developers hate. All those things are mostly the teambuilding activities that most managers love and most developers hate. They’re also the reason why remote work is so much more efficient.
I’ll write some more on managing the remote team separately, but the key point is this — it’s doable, it’s much more efficient than in-office work and you can get all the benefits of in-person team building by having regular offline meetups with your team — you can literally fly your team members to spend some time together every 3–4 months using the money you save on renting the office space.
Foster an Engineering Culture
To build a strong engineering culture you need strong technical leads that care about what they’re doing. There’s a lot of facets to it, but it boils down to the fact that we, developers want to play with new and shiny toys, and don’t like when we’re bothered with a lot of beuracratic nonsense. One must say that it’s work and you gotta do what you gotta do, and would be right. But when your’e competing for talent, an approach like that is not gonna give you any extra points.
Thing is, software development is a creative job, even though it might not look like from a distance. Good engineers never work on the same problem twice — it’s always a new challenge. To keep the creative juices flowing for 40, 60 or sometimes 80 hours a week, there should be a “play” element at work. Because if there’s none, your engineers will do what they have to do, but then they come home and play around with the tech they want to try on their spare time. Otherwise you’re working with someone who’s in it for the lucrative salaries, which never worked out well in my experience.
Sure, there should be a fair share of serious work too — we’re all adults and understand that there are bugs to fix, boring but valuable features to build, technical debt to address and so on. But there should be a creative outlet, otherwise the job gets too grim and that’s a serious putoff for us, geeks.
Promote Open Communication
In our team, we have an “open communication” policy, which means that everyone seems everything but the most critical documents protected by privacy and NDA agreements, and of course the customer data that is kept separately.
This means that develpers on the team can see all the requests that users send, analytics on how people use the products we build, design mockups including the future ones, roadmaps and discussion around them and many more. They rarely look at them unfortunately, cause there’s only 24 hours every day and a lot of stuff to do, but they can if they want to.
Often, when we discuss a new feature engineers actually go and study all the available documents, and that’s where get heated debates that sometimes last for weeks about whether we should do certain things and how we do it.
We had a quite heated debate on how to implement an AI chatbot recently (speaking about the new exciting technical stuff to play with), it looked like a fight and every participant was standing the ground. In the end, we found a short-term solution and agreed to improve it later so deliver the feature and the value faster.
If developers aren’t encouraged to voice their opinions and oppose the authority (for example me, the CEO, in the case above), everyone will just agreed to do as they’re told to. While this might work for some time, it will lead to a growing unhapiness in the team, and also missing critical information to make the right decisions.
Give Autonomy and Ownership
“Tell me what you want to do and let me decide on how to do it”. That’s how I would translate the heading above from a managerial talk above. David Ogilvy, one of the masterminds of the business world of 20th century, said it well — “Hire people who are better than you and then leave them to get on with it”. This quote sounds so obvious when you read it, but it’s not that obvious when you’re actually start building the team.
See, we all have our fears. One of the most common ones is that you will hire someone who’s smarter than you and thus will pose the danger to you. As a company founder, you might fear that a smart person will learn the know-how of the business, or will steal your clients, or the whole business. So you aim for someone who won’t. Same way, as a manager, no matter what level, you might be afraid that you’ll hire a better manager than you, the CEO or a founder will see it and you’ll loose the job. As a tech lead you might fear the same.
Same way, often times founders, CEOs and managers are afraid to let go and let the inmates run the asylum (that’s the name if a great book by Alan Cooper, read it if you haven’t year) fearing of loosing control. But the paradox is that the only way to make progress is to find the best person you can work with, trust that person and let go of control, hoping that they will do everything right. Otherwise you will constantly have to micromanage and deal with subpar performance.
The key is creating a work experience centered around trust, transparency, autonomy and enablement. This allows you to attract and retain talented engineers who will be intrinsically motivated to do their best work. The soft factors highlighted here are just as important as compensation when it comes to retaining software engineering talent.
Let me know if you would like me to clarify or expand on any part of the edited post! I aimed to improve readability while maintaining the original voice and content.
Originally published on Medium.com
