Posted in:

For security reasons due to the nature of the information contained in this document, a valid email address is required to allow downloads.

Your Email (required)

Should You Use Recruiters?

Posted in: Consulting & Entrepreneurship, Software Development Team Leadership

There has been a good debate on the Los Angeles Java Users Group mailing list this week about working with recruiters, both from the job seeker side and also from the employer side.

In my career I have worked with recruiters on both sides of the fence and I think the argument boils down to the same issue no matter which side you are on – working with good recruiters is a good idea and working with bad recruiters is a bad idea. Apologies if you were expecting something more earth shattering!

Many recruiting houses are simply glorified keyword matching services and they all function almost identically. If you visit their offices you will find a large room with two large tables, one designated for “Hardware” and one for “Software”. All the folks around the Hardware table are working to fill Hardware related positions and the Software folks are doing the same for Software positions. There will be 4 to 8 folks at each table, each with a computer and a phone permanently strapped to their head. At the end of each table will be a large white board with the “Hot Jobs” listed with the keywords to try and match, plus salary and commission rate (not surprisingly the higher the salary and commission rate, the hotter the job miraculously becomes). The main purpose of the folks at the table is to process the highest number of resumes as is humanly possible (from active job board postings, from their DB of past resumes etc.) and bring the resumes with the best keyword match to the top of the pile, then do a bare bones phone screening interview (ie. does the person actually exist) and then pass the pile of resumes off to the employer. The employer then has to process the resumes all over again, screen out 80% of them because while the keywords are there, there is an obvious problem elsewhere and then interview the other 20% to find out if any are even close. Most of the time you can achieve the same results as an employer by paying the fees to and doing the search yourself – it might even be quicker.

But as a job seeker you do need to be in contact with recruiters because many positions are never posted widely/publicly (at the request of the employer). In this scenario the employer is engaging the recruiter to get at their pool of contacts that are hopefully pre-screened etc., some of which may not even be in the active job market, but are known to the recruiter. This becomes increasingly true if the position being filled is higher up the corporate ladder (manger, director, VP etc). However, a bad recruiter will waste a lot of your time if you are not careful.

As a manager, these keyword matching recruiters are the bane of my existence and 50% of the reason I never answer my phone at work (the other 50% of the reason is software sales guys, but that is another post). The endless cold calls just trying to present me “a really exceptional candidate” they have found or “just wanting to know” if I have any open positions. These guys are really the sleazy used car salesmen of the IT industry.

As a job seeker it will be pretty obvious if you are working with one of these houses. Firstly if you ever get a phone call in response to a resume you submitted and it sounds like the person on the other end is sitting in a room full of people talking loudly, then they probably are. I have even been asked to hold the line when talking to one of these guys and while I was waiting I could hear another recruiter at the table talking to another candidate on their phone about the exact some position!

One of the other classic traits of these organizations is their incessant need to keep the job seeker and the employer at arms length from each other – the theory being that they need to control the communication stream so as the employer and the job seeker don’t reach their own agreement and the recruiter misses out on a commission. This is a symptom of the fact that the recruiter and the employer are not closely engaged with each other and do not have a strong working relationship. This also just hurts your ability to present the best of yourself to the employer. You are the person who knows your skill set and experience the best, and yet you are letting a recent high school graduate with 2-days in house training represent you. Another tactic is for these houses to take your resume and rebrand it with their logo and add their contact information and remove all of your own contact information. This involves a cut-and-paste from the resume you submitted and invariably ends up in a less than professional looking document. Just wait until one of these guys takes it upon themselves to actually edit the content of your resume “on your behalf” without asking you and you will very quickly realize that these guys are probably hurting rather than helping your job search.

Also, just be a little wary about the employer if they are using these kinds of companies. Its probably not a deal killer for you as the job seeker, but just pay close attention to what else your employer might not be paying close attention too.

But! There are good recruiters too, they are just a little harder to find.

I have worked with good recruiters on both sides of the fence as well. From an employer perspective a good recruiter who knows your industry and knows the local talent pool can be invaluable. They can help you shape the job description and salary of an open position to align it with what is happening in the rest of the industry and so attract the type of candidates you want. They can find candidates that are not in the active job market because they have built up a high quality contact list of candidates they have placed in the past or have met during prior searches etc.

These recruiters are usually smaller shops with a smaller focused recurring client base. Many work on a mix of retainer and actual placement fees, so they are not all about placing as many people as possible, they have an incentive to establish and keep long term relationships with employers by providing exceptional candidates.

From the job seeker side you will have to do your research to find these kinds of good recruiters. They probably won’t be posting hundreds of jobs on because they simply are not filling that many positions at one time. All of the ones I have dealt with in my job searches have found me, not the other way around. When they call you, the background of their side of the conversation will be quiet, because they are not working in the bull pen, they actually have an office! They will likely want to talk to you for a while and have an actual conversation. They will want to determine if you are an all around good candidate, not just a good keyword match.

If you are presented to an employer by one of these trusted recruiters, you are going to be going into that interview with a lot of credibility already on your side. Plus you already know you are one of just a few folks that are going to be interviewed, because that is what the employer is paying for – to not have to do hundreds of interviews.

So in the end, a good recruiter is someone you want to be in contact with, no matter if you are an employer or a job seeker. A bad recruiter on the other hand can waste a lot of your time and also actually hurt your chances of finding a job or filling your position.

Stay Out Of My Business!

Posted in: Software Development Best Practices, Software Development Team Leadership

If you have a software team in your company, it is (hopefully) stocked with highly trained engineers that are well paid and know what they are doing, or know how to figure out what to do in a timely manner. They offer the best value for money to your company when they are empowered to make technical decisions, after all, if they are not the technical authority in the company, then what are they there for?

It doesn’t make much difference if the company is an ISV or an internal IT department serving internal customers only. At the end of the day, you have a software team serving customers by providing software based solutions to their problems.

The customer’s role is to provide what are normally called “user requirements” or “functional requirements” – in other words they need to tell the software team what it is that they want the software to actually do for them. It stands to reason that the customer is the best person to ask what the software they are asking for should do.

Now, it is very common that the customer struggles to tell the software team what it is they want. Either they really don’t know, or they think they know but turn out to be wrong. Both of these “incomplete requirements” scenarios can be handled using an agile development process so they should not present a big hurdle for a competent team. The basic premise still remains, the customer’s job is to provide functional requirements, no matter if they give them all up front, or piecemeal along the way.

From those requirements, the software team is charged to implement a solution that implements those functional requirements. As I proposed above, a software team designing and implementing software is the highest and best use of their time. So this scenario sounds like the perfect environment for quality software to thrive.

Of course finding a company that fosters this environment can be hard. Often the culprit that violates this nirvana of quality software is the customer that doesn’t quite know where their responsibilities begin and end. You can smell this happening when functional requirements documents contain statements that refer to specific technologies or architectures. For example, a functional requirement that states “The UI will be implemented using technology ‘X‘ because it is the only one that can handle the requirements” should be an immediate alarm bell. It seems benign, but there are many problems that can manifest from a requirement like this.

The obvious first problem is you have a group who are not the technical authority making technical decisions. This is a political, social and morale issue. Technical people like making technical decisions, that’s why they are technical people and not marketing or sales people. If you take away their ability to make technical decisions they are likely to resent it, their buy-in for the project will drop, the morale will drop and the result will be an inherently lower quality output.

Another problem is that you have less qualified people making technical decisions. If your customer is more technically qualified than your software team, you are probably doomed before you begin. If this is the case for you, forget reading the rest of this article and start polishing your resume. A good software team should contain members that are relentlessly exploring new technologies and trends. Without question your software team will have a deeper knowledge of all possible choices and the ramifications of one choice over another.

Software teams contain a lot of knowledge that is not necessarily written down in policies, procedures or architecture documents. This latent knowledge base is the main value of the team. It would be impossible for an outsider to posses most of this knowledge, particularly the knowledge that is specific to this team as opposed to software in general. The reasons behind certain tradeoffs made 2 releases ago can be a critical knowledge point to have.

This latent knowledge is a double edged sword though. I have seen many meetings between customers and engineers where an engineer will discount a suggestion from the customer, and when the customer asks why the engineer struggles to answer even though he has the knowledge. I like to think of it like breathing. You know that breathing is remarkably important, in fact you do it all the time and you really couldn’t imagine doing anything else. And yet if someone asked you how to breathe, it is quite difficult to explain, particularly if you are talking to an alien that doesn’t have lungs and doesn’t understand the basics of human respiration. Well that might be taking it too far, but the point is valuable. Another analogy is a human trying to explain their existence to an ant. Ignoring the obvious communication issue, the conceptual argument offered by the human is completely incomprehensible to the ant because his reality is so different to the human. So basically, trying to explain software development to a layman is often difficult simply because you have no common reference point and no common language to use. If you try, you will often cause more harm than good.

So is there a time when a customer should define technical requirements? The answer is a definite yes, with a closely followed maybe. A customer can have legitimate constraints that need to be observed. Call them “environmental requirements”. For example, needing the software to run in a Windows environment because that is all the customer has on their 2000 desktops, is a reasonable requirement for the customer to have.

A requirement stating that the software must be browser-based because the customer’s IT department doesn’t want to have to install the software on the 2000 desktops also sounds reasonable. But then the question for the software team is, what does “browser-based” really mean? What if the software could be developed using something like Java WebStart (a sort of browser/thick client hybrid), is that going to be acceptable? What if the software is inherently better delivered that way because of the rich UI that is possible? Clearly this second requirement could restrict the choices of the software team to the extent that the quality of the solution may be affected. The key is to get at the true underlying requirement. If the requirement was restated as “The solution should have a zero-install profile to reduce TCO”, then the software team can achieve the requirement and still have their hands untied to find the best technical solution.

Is the opposite true? Can the software team impose functional requirements on the customer? Again the answer is a definite yes with a closely followed maybe. If the development process is one in which the requirements are written up front and development happens later, then input from the software team is very difficult to take into consideration. Don’t forget, the software team is usually the first ones to use the software being constructed as they test their code. They will often find design defects very early on. Being able to provide that feedback to the customer is highly valuable. That value increases exponentially in an agile development environment where that feedback can be acted on quickly. In the end, the functionality needed is the customers decision, and suggestions from the software team may be ignored for very valid business reasons. Software teams simply need to swallow that pill, you can lead a horse to water …

I have talked about the highest and best use of software development team resources, but the opposite is also true for the customer. If the customer manufactures fridges, then the highest and best use of their time is working with fridges. If the customer is the internal marketing team, then the highest and best use of their time is doing marketing things. If that isn’t the best use of their time, then they are on the wrong team.

The quality of the output of a software project is improved when customers and developers are aware of their responsibilities and work within them. The quality is improved exponentially when customers and developers are also given the ability to provide feedback in both directions and when the development process empowers both teams to act on the feedback quickly.