More Efficiency: How to Hire Developers When Hiring Gets Tough
Almost every company is looking for software developers. As a result, organizations need to look beyond mere recruitment and find other ways to achieve a fast time-to-market for their products – and the key is to make your development teams more efficient. If you can’t grow your team, then use efficiency to enable it to deliver more value in the same time.
Fishing in an empty pond
When scrolling through my LinkedIn feed, many of the posts I see are about open positions, especially in software development (admittedly, my industry bias will have some effect). Companies are trying really hard to attract talent, but even if there are perks, a more than competitive salary, and a high-profile role, this doesn’t lead to more applicants, let alone more hirings.
The reason is that the competition for talent in a scarce environment such as software development is so fierce that a good or even great offering is not enough – developers need to find you, and you need to attract their attention. Then there should be a cultural match (which, unfortunately, in many cases, is omitted to make at least some progress).
In short: the shortage of software engineers will get worse, not better, and just hoping that recruiting will get you where you need to be to deliver your products and services will not suffice.
Finding the efficiency killers in the software stack
Certainly, it’s not cracking the whip (try that with developers, and that’ll be the last you ever see of them), and if you have already covered things like working environment, team dynamics, time management, leadership style, and other “soft factors,” you should move on to taking a look at your tech/software stack to find substantial efficiency killers that are worth tackling.
The trouble with the technological hunt for efficiency is that any gains are usually harder to achieve because they require more than just a policy change or a higher paycheck. Nonetheless, not tackling them means that you risk falling behind the competition regarding time-to-market and will also end up with a higher churn rate of your development team as developers tend to dislike inefficient systems and tools.
In the current hiring crisis, this is something you should always keep in mind and not underestimate.
We are convinced that efficiency starts with the developer experience. Suppose you can make code work not just a positively challenging experience but also as delightful as possible by removing inefficiencies. In that case, you will have better software, faster, and a thoroughly motivated and loyal engineering team.
Better development efficiency will support your time-to-market and competitive advantage, and also result in a modern tech stack which increases the likelihood of your developers staying on board.
Some questions to get you started on leveraging developer efficiency:
1. How modern is your tech stack?
Take a look at which programming languages and frameworks are currently in use. There is no general rule about what is truly modern and what is old-fashioned or outdated – the reason behind this question is the assumption that the older the stack, the less efficient it is. This also applies to mixtures: the most modern framework in use will hardly be able to compensate for an old database or a legacy component you have to integrate with.
This does not mean that the stack you’re using is inefficient in its operation – in fact, I have seen many well-integrated legacy-type stacks which perform flawlessly and “get the job done” – but what we are looking for is developer efficiency, so the question is: how much effort is it for your development team to actually change or debug something in your stack? And in this respect, it does matter if your stack is modern (usually well-documented) or not. For example, in my years in the travel industry, I have seen mainframe applications written in COBOL delivering a lot of MIPS (if you have to google this, you probably have been born after 1980 😉 without a hiccup. However, in case of a problem or program change, senior (both in age and experience) programmers had to come in from their retirement to take care of this, and changes on the host aren’t for the weak of heart.
A modern, homogenous tech stack is a good facilitator for efficient software development.
2. How complex is your tech stack?
So your stack is modern enough, but what about its complexity? The more technologies you have in parallel use doing more or less the same things, the less efficient you’ll be in developing in this environment. If possible, go for one solution for each problem in your stack – even if you miss out on some efficiency in a particular portion of the stack, having less is more. For example, vue.js and React are both great front-end frameworks, but you should opt for one of them.
If you intend to use both, I recommend keeping their use cases separate. The point is that regardless of a valid use case for multiple solutions in the same area, it will always increase the complexity your developers will have to manage and thus consume additional time. Even if you find yourself in the luxurious situation of running dedicated teams, you should ask if this is indeed the most efficient approach, especially if your teams aren’t fully staffed.
Try to find solutions that don’t overlap in your stack to keep things simple and manageable.
3. How much technical debt is incurred over time?
Technical debt is leftover work after something has been shipped; the classic “we will fix this later” religion almost always leads to things not getting done and falling at your feet when you least expect it (and in the most inconvenient moment, of course).
Technical debt can, but doesn’t have to be an indicator of a lack of efficiency. If your teams are constantly facing a lot of it, better efficiency can help decrease the amount of technical debt if the management is smart enough not to reduce the time allotted to specific tasks at the same time.
Be mindful of technical debt as it eats at your efficiency in delivering value and reduce time-to-market.
4. How much repetitive work are your developers doing?
The goal is to only do the necessary steps as seldom as possible. Whenever your team does things repeatedly, ask yourself if this can be automated with reasonable effort to make an ROI that works for you.
Most importantly, involve your team in looking for automation potential. Your software engineers are skilled and knowledgeable about finding tools that work for them – and that’s a critical aspect. If you impose a tool or process on your team without involving them, you will likely meet resistance and will have a hard time achieving that ROI you promised your CEO. My advice is to always go developer first with this – if you have a lead architect, ask her to come up with suggestions. If not, ask someone from your dev team to take the lead in finding a solution or make it a team challenge. If you already have a solution, be smart about it and ask your team to review it – or simply ask for advice or feedback. This is not a sign of weakness but of empowerment and good leadership.
Automate what you reasonably can, and always involve your development team to find solutions that your engineers like and support.
5. How many software dependencies does your team have to manage?
As solutions grow, so do dependencies. If you are running a monolithic system, this can quickly become a nightmare to maintain (if it isn’t already). Still, even in a modern microservice architecture, managing dependencies through APIs can be tricky, especially if you have a zoo of APIs to connect, maintain, and secure. Reducing these dependencies is probably the most critical lever on efficiency but can be a challenge depending on your system complexity and share of legacy services.
However, you can get those APIs under control and make sure you have as little effort working with them as possible. Every API you don’t have to actively manage will give your team a lot of time, and if you multiply that across all your APIs, you will end up with a lot of time that your developers can now spend on value creation.
Yes, development efficiency makes a difference.
Even if you tackle just a few of the efficiency killers discussed above, you should see an impact on your delivery speed and time-to-market. If the impact is profound enough to replace hiring new developers depends on the team size and the inefficiency level, but shaving even 2 hours off the workload of a five developer team per week gives you more than a day’s worth of developer impact per week.
Of course, this doesn’t scale indefinitely. Once you have optimized your tech stack and all that goes with it (which is a theoretical state, of course), you may still need to hire software developers. But by then, your company will be more attractive to developers.
This article was written by Stefan Avram for HackerNoon and was edited and published with permission.