I've been in a management position for the better part of the two decades I have worked with development. From a simple team manager, with little or no influence as to whom and when I would hire somebody, up to actually hiring the people responsible for hiring people.

I'd like to say that I have a 100% record of successful hirings, but that would be a lie. Over the past two decades, both as an employee and as an employer, I've learned a lot about hiring developers, and I'd like to share with you some of my processes and ideas.

In this series of posts, I'll show you how I tackled all these questions and more, over the two decades I worked in advertising agencies.

Disclaimer: This is not a definitive guide on how to hire a developer and I am not saying my way is the only right way to do it. There are thousands of other methods, scenarios, conditions, and so forth, where my processes will not apply.

When to hire?

The first real question. When should you consider hiring a developer for your team? I have found that most companies go about this the wrong way. There is a tendency of only hiring new developers when your current team is swamped and on the verge of Burnout.

This is not the way to go. I've always strived to keep my team with a 70%-80% workload. This can seem like a waste of money for some, but I've realized that developers, like any other human, need time to think and to decompress. A healthy (both mentally and physically) developer, will churn out code better and faster than an overworked one.

An added problem to hiring people when your production level has reached its peak is; your new developer will need some time to adjust, get to know his place in the team, understand work processes, and so on. If all your devs are freaking out with work, tired, mentally exhausted, and, behind on their work, it is very unlikely that your new developer will get the attention he/she deserves.
Actually, it's more likely that the developer will get overwhelmed with work, and instead of developing at full potential, he/she will be swept away by the tide and add little to the team. Congratulations, you've just hired an employee about to burn out too, and not to mention, you've just added more overhead to your existing exhausted developers.

PLANNING IS KEY

You most probably have some control over what your team is up to. It's up to you to know what are the Key Performance Indicators(KPI) of your team's output. What the basic feeling of the team is, and what are the upcoming challenges they'll probably be facing in the not-so-distant future. If you don't, then I would suggest that you, before hiring new developers, at least get some organization in place. Know what to expect from your team, figure out how to qualify what they deliver. It will pay off very quickly.

A tangible example

I worked in an advertising agency and most of my projects had the following characteristics:

• They were short-lived (which meant little or no maintenance).
• They fell into three general categories - common company sites, promotional sites, and bleeding-edge technology sites.
• Time to market was usually very short.
• Demand was a bit sporadic.

From this, I had a few KPIs I would assess my team on. The main one was the number of iterations I had with the Q&A department. If they had many issues with my team's delivery, I would know something was off. There were a few KPIs I used besides Quality, another one was code libraries for re-use, and obviously, conversations with my team.

Besides the occasional demand surge, I knew roughly how much work our team had each month. I also knew how negotiations with clients were going and I had time to plan.

Replacement

People change. They might have been promoted, had a better offer, they might be pursuing a life long dream, they might lack challenges, or they are just looking for a change.
Whenever that happens, I personally prefer to replace the developer with someone from the team. Let's say my senior developer quits; I'll usually prefer to "upgrade" a mid-level developer to senior-level rather than hiring an external resource. I'll fill the opening with either a mid-level or junior-level and let them grow. I find this is the easiest, both on the team and with the new developer. (Added bonuses include: you are bringing in a fresh mind that can have time to adjust to company culture; people in the team see a clear chance of growth; teams usually deal better with welcoming lower-ranked developers rather than adjusting to higher-ranked ones - again this depends on your team).

Obviously, it's not always possible to do this, and sometimes you'll need to hire a replacement for that specific opening. When something like that happened, I usually talked to the team before hiring, and whenever possible, had the team participate in the hiring process. It makes for a smoother transition.

Finally, on replacement, don't replace a developer because he/she is currently under-performing without giving it the required time and thought. Sometimes, people just are going through people problems. Talk to your developers, understand where they are, why they are where they are and align expectations. You'd be amazed at how much better a developer can get if you start treating them like people rather than machines.

Growth

If the demand for your team is on the rise, you'll have to hire new staff. If you have some planning, you'll know when to do it, it's usually a no-brainer. If your team is efficient and no optimization can supply this demand (by automating tasks, using tools and so on), then you'll need to grow.

Temporary growth is not a reason to hire

If you are hit by a huge surge in demands, like I was a couple of times, you have options like freelancing, temporary contracts or even hiring companies. I don't think I ever hired a full-time employee in this scenario. Hiring with responsibility is a key factor. You are changing someone's life. They are changing their life based on a job offer you gave them. If you hire them, just so that you can let them go 90 days later, you could have just hired them as a temp. In a nutshell - don't do to others what you don't want done to you.

Specialization

I've had situations where a client would have a very specific need and we had to hire somebody with that specific knowledge. I am not extremely comfortable with this kind of hiring, as, inevitably you are linking an employee to a very specific scenario. Any change to it could mean having to let go of the employee.
Discuss options with your team before going down that road. Hire a temp or a consultant to give you some time to assess the field. Again, it boils down to responsibility.

Oportunity

In Brazil, we have an expression "Mosca Branca" (literally translates to White Fly) which is used as an adjective for extremely rare. It's the equivalent of a four-leaf clover I'd guess.

There might come a time when you will bump into a developer that simply blows your mind. I had that a couple of times in my career. We would outsource some jobs, and there were two occasions when the freelance developer was just so amazingly "a perfect fit" with our company and team that I brought them in, independent of actually requiring them at that time.

Again, I had two of these in over twenty years. I also must mention that one of these hirings back-fired. The developer soon discovered that he was better suited as a freelancer than a fixed employee.

Conclusion

If you got this far, I guess you've seen a common component in most of the scenarios: planning.

Plan your hiring. Don't go wild and hire two dozen developers to create a single e-mail marketing HTML. Also, don't overwork your current team and suck them dry to the bone. Keep in mind that each developer is, above all, a human. Replacing developers in your team is a costly procedure. It costs the company money, it costs your team time and emotional strain, it costs the employee and yourself time and stress.

Make sure your team is well organized and as efficient as they can be before going down the hiring road. Adding developers in a messy and inefficient team will, 9 times out of 10, create more mess and inefficiency.

As I said a couple of times above, be responsible. As a manager, I have always looked at a developers job as something both the developer and I were responsible for. With that in mind, communication has always been an essential component in the work relationships I have had. With an open communication channel with your development team, it is usually crystal clear when you need to hire new staff members to ensure that the engine still runs smoothly.