I’ve liked Minus the Bear for awhile now…just something catchy about their sound. I was pleased to find out they’ll be playing a music festival north of Seattle this summer.
You may not like Zappa, and you may think Stairway to Heaven has jumped the shark, but trust me, this is worth a listen.
A friend of mine sent a message to an handful of friends today:
I got my first phone interview lined up and I’ve never done this before. I would love some pro-tips on making it successful.
I’m not sure if these are actually pro-tips, but here’s what I offered:
1. Have a piece of paper and pen in front of you.
2. Take a moment to think before answering.
3. Don’t be afraid to respond to their question with a probing, clarifying quesiton…so that you can answer it more in line with what they want.
4. Be yourself, you’re awesome as you are!
What would you have suggested?
I really enjoyed reading Donald Miller’s A Million Miles in a Thousand Years, and a central part of that book is Miller learning about the structure of a story. In the book, Miller attends Robert McKee’s “Story” seminar in LA where he learns the essential structure of a story: a story is about a character who wants something and must overcome obstacles to get it.
I reminded of all that today when I saw this in my son’s 2nd grade classroom:
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?
In this week’s I Need More Ears, we have a special guest appearance from Toby McKes. He shared this story with me, and it was so amazing, that I asked if I could share it with you:
About 10 years ago, C89.5 started playing this song…it was a mashup before mashups were a thing. And, it was the most glorious mashup my young ears had heard. It was the instrumental from “Let’s Groove” by EW&F, with the vocals from an Elton John song I had never heard called “Are You Ready for Love”.
They played it all summer and I fell in love with it, so I called the station and asked who it was by, but they didn’t know. They told me that it arrived in one day at the studio in a blank envelope containing a CDR that said “Elton John” on it.
So, I made a crummy rip of it from the bad online streaming back then, complete with skips and system sounds in the background, and that was all I had.
Over the last 10 years I’ve tried to find it on the Internet with no luck. Then, last week I found that crappy mp3 I made 10 years ago on an old backup hard disk, so I tried to find the song online again.
I found a Youtube video of it with a DJ name attached to it. I contacted the guy (found him on Facebook) and he pointed me to an old mp3 store site (from the pre-iTunes era) where I could buy it legitimately.
So happy! :D
A little bubble gum never hurt anybody on a sunny spring day…enjoy!
Olivia: One thing I’d add to your post might be that you have to go into iterative efforts fully open to the fact that the “Loop” step might mean you took at wrong turn and need to stop and/or kill what you’ve done. Otherwise, you wind up with Winchester Mystery House product and resources spent supporting worthless crap. And killing something off is suuuuuuper hard to do, from what I’ve seen. But it’s part of that whole “committing to the Loop”…that’s the toughest part.
Me: I’m not a good killer. I love all my children.
Olivia: Yeah, it’s really, really hard. There’s always the question of “Is this not working because it’s a bad idea?” or “Is this not working because we didn’t sink enough time into making it a kickass feature?” But research should point you in the right direction, ideally. If you’ve got time to conduct it. And no crazy backlog of features that your CEO wants “right now right now!” to deal with. And killing stuff off is logistically painful. “Hey users, remember that feature we put out? Well, not enough of you like it so we’re ripping it out. LOL!”