This post highlights an alternative to just hiring developers through all possible channels. By leveraging development efficiency potential, you can scale your business even if you can't fill all open engineering positions. A possible approach is to analyze your current tech stack and find efficiency killers.

When hiring developers gets tough, focus on developer efficiency

Almost every company is looking for software developers.
As the complexity of applications grow, security challenges increase and interfaces multiply, it is obvious that the scarcity of skilled software engineers will not disappear,
but will become even more severe as demand outgrows supply.

As a result, organizations need to look beyond mere recruitment and find other ways to achieve a fast time-to-market for their services - and the key is to make your development teams more efficient. If you can’t grow your team, then enable it to deliver more value in the same time.

Fishing in an empty pond

When scrolling through the LinkedIn feed, many of the posts I see are about open positions, especially in the area of 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, a high profile role, in many cases 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, you need to attract their attention, and 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 in order to deliver your products and services will not suffice.

It’s like time: no matter how hard you try, a day will not have more than 24 hours - the only thing you can do is make better use of the time available to you. So what can you do to make your programmers and engineers more efficient and productive (after you’ve tried extra coffee, candy and club mate)?

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 saw of them),
and if you have already covered things like working environment, team dynamics, time management, leadership style and other “soft factors” (which warrant their own blog post at a later date), 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 pay check.

Nonetheless, not tackling them means that you risk falling behind the competition regarding time-to-market and,
at the end of the day 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. As a developer-first company, we at WunderGraph are convinced that efficiency starts with the developer experience.
If you are able to make code work not just a positively challenging experience, but also as delightful as possible by removing inefficiencies, you will end up with 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.

So where should you be looking for the efficiency potential?

Some questions to get you started on leveraging dev 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 what is truly modern and what is old-fashioned or outdated -
the reason behind this question really 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.

As an 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 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 you 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 both are great front-end frameworks, but you should opt for one of them.

If you intend to use both, I would recommend to keep their use cases strictly separated. 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 left-over work after something has been shipped; the classic “we will fix this later” religion
which almost always leads to things not getting done and falling on your feet years later when you least expect it
(and in the most inconvenient moment, of course).

Technical debt can, but doesn’t have to be an indicator for 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 certain 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?

Even if Fred Taylor would love to see your developers doing the same things over and over again to become super efficient at it, it’s not the kind of efficiency you want (and developers don’t like Taylorism).

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 for a 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 are likely to meet resistance and will have a hard time achieving that ROI you outlined to your CEO before. 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 of your dev team to take the lead in finding a solution, or make it a team challenge.

If you already have a solution in mind, be smart about it and ask your team to review it - or simple 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), but 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 important lever on efficiency, but can be a challenge depending on your system complexity and share of legacy services.

However, what you can and should do in any case is get those APIs under control and make sure you have as little effort working with them as possible.

WunderGraph’s approach is to automatically create one unified API for all your data sources as we believe a developer shouldn’t have to worry about individual APIs.
In fact, every API that you don’t have to actively manage will give your team back 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.

Dependencies are a big lever to save development time.

Start with your APIs first and consider using a framework like WunderGraph for API automation and management instead of doing it all manually.

WunderGraph is going Serverless in the coming months. Join our waitlist to be notified when we go live and to get early access to explore serverless API Integration.

Yes, development efficiency makes a difference

Even if you tackle just a few of the efficiency killers discussed above, you should see an impact in your delivery speed and time-to-market.

If the impact is profound enough to replace hiring new developers depends on the size of the team and the level of inefficiency, but shaving even 2h off the workload of a 5 Developer team per week gives you more than a day’s worth of developer impact per week. Imagine what this team alone can do in a month with a week more of development time on their hands.

Of course, this doesn’t scale indefinitely. Once you have optimized your tech stack and all that goes with it (which in itself is a theoretical state, of course), you may still find yourself in the need of hiring software developers.
But by then, your company will be so attractive and the impact of each software engineer so substantial
that every hire will deliver maximum impact.

It’s a nice vision to aim for.