I had coffee with a friend who recently entered the staffing agency business. His company has several hundred developers on staff, and each of these have been technically vetted. So, the idea is that a company can easily increase its engineering resources by calling up and saying, “Hey, we have a new project and need <insert some number> engineers next week.” Yes, you will pay a higher rate for the resources, but you’ll get them when you need them, and don’t have to incur the ongoing cost of full-time employees after the project is over.
Naturally, he was asking if Rover could use his services. Yes, we are hiring, but no, we are already working with some recruiters, and are not going to add any more at this time. (Hint: recruiters, don’t call…I’m not going to hire you right now.)
The conventional wisdom is that startups and young companies don’t want to hire through staffing agencies because of the higher costs. In part, that’s true, but it’s not the real reason. Most companies would gladly pay an extra cost for great developers immediately.
The real reason is that a young company like Rover isn’t well-suited to use staffing agency resources. How are we not well-suited? Let me count the ways…
There is a big cost for us to bring a new employee up to speed. As a young company, our software isn’t well-documented and we have yet to establish robust, yet efficient, training programs. Part of value of a staffing agency is that you can get the developers quickly, but you can release them easily when the project is over. Yet, we have to invest in a new employee which means we want them to be here for a long time in order to recoup that investment. In other words, the “releasability value” isn’t valuable to us.
One of the things that helps new engineers be productive quickly are thoroughly written product specifications. Startups are notorious for not spending a lot of time on specs. Often, the entire spec is a just a sticky note, for example, “Add promo box on checkout”. What? There is no way a new engineer to know what they should do. In that case, the engineer needs to be familiar with the system, so now we’re back to the “up to speed” problem. Or, to get the “quick availability value” the company needs to invest in writing more detailed specs, and that further increases the costs.
Soooo, who then, are technical staffing agencies good for? This is what I talked to my friend about this morning, and I thought I’d share those ideas to get your thoughts. (I’m curious to hear what my recruiter friends have to say about this.)
Scott’s ideas for questions for technical staffing agencies to ask of firms to see if they might be a good fit:
1. Obviously, companies that spend a lot of time on product planning and specifications will be more suited toward flexible resources. So, asking about the planning process, the number of planners (i.e. product, project, program managers), asking about the importance of details specs versus agile flexibility…these are good things to find out if you’d be a good fit.
2. Ask if the company’s software uses a “service-oriented architecture”. An SOA is a type of technical design where components of the system (i.e. services) are completely independent and only interact with other services via an API. (An API is a pre-defined programming interface that allows computers to talk to each other.) An SOA provides a lot of flexibility to the stuff behind the API; as long as the API does what it’s supposed to do, then it doesn’t matter how it gets done.
For example, if there is an email sending service, as long as other software components can connect to that service via the API and the emails are sent it doesn’t matter if you have fancy software doing it or a bunch of hamsters. All of that is hidden from the outside.
An SOA has a number of signatures that indicate it’s a good fit for flexible staffing resources. Since an SOA relies on APIs, and an API is a pre-defined interface, then that means it requires a thoroughly written spec. You know who else relies on a thoroughly written spec? That’s right…developers from technical staffing agencies.
Additionally, the independence of each service in an API make it easier to test. As I said, as long as the service does it’s job, it works. In other words, the internal quality of the system is less important because it doesn’t impact the whole system.
Finally, an SOA is language-independent. You can write your service in C++ and I can write mine in F#, Z-flat or Q-minus. All of the services will communicate via a common mechanism, so the language doesn’t matter as much.
3. Ask if the company uses a “message bus”. I guess this is just another flavor of SOA. In other words, a message bus is a signature of an SOA. So, if you’re a technical staffing agency, asking if they app uses a message bus is a good thing to ask.
Now, if you’re a sales guy at a technical staffing agency, you might not have the chops or nerve to just ask, “Do you use an SOA?” Maybe a better approach is to say, “I’m trying to learn more about system architectures because I think that will help me better serve my clients…what’s your system like?” Or, “I’ve heard this SOA buzzword…can you explain that to me?” Or, of course, you could just read and get the chops.
So, thems be my thoughts for the day….whaddya think?