I reminded of all that today when I saw this in my son’s 2nd grade classroom:

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?

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

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!”

Okay, take a deep breath…let me Take a Step Back™…because I started with the conclusion.

All the rage these days is talking about iterative development and emergent design.  If you’re in the business, you know what I’m talking about.  If you’re not, a bit of background:

The way a house gets built is “stage-based”.  You start with a idea, and you turn that into a plan by working out every detail in the blueprints, then the house gets built and after it’s built the city building inspector signs off that it’s safe, and finally you get a certificate of occupancy and you can move in.  In other words, there are many stages, the project moves through each stage step-by-step.  Software people call this stage-based approach “waterfall” (often derisively).

At Cheezburger I kept a wall of sticky notes with bits of wisdom I have learned over the years.

For a variety of reasons, when building software it is often less efficient and/or less effective to use a stage-based approach—to make a plan, build the software, then test (i.e. inspect it).  Sometimes it’s better to just start building, see what happens and then adjust.  This is called emergent development because you let the software emerge, as opposed to planning the desired outcome.

The whole notion of emergent forms of construction is that they are iterative.  That is, after building a little bit of the software, you try it out (or let the customers try it out), then you go back and make some changes based on learning and feedback.  This iterative process is referred to as the “Build-Measure-Learn Loop”.

• Build: make the thing, software or whatever.
• Measure: have people use it and observe how well it works
• Learn: based on the observations, figure out what would work better
• Loop: make changes to the thing based on the learnings

What makes an emergent system work well is that taking by baby steps, building the system one bit at a time and seeing what’s working, then you can correct course before investing too much time and effort into something that doesn’t work or meet the needs of the users.  Correcting course, in this case, is Loop, meaning you re-build or adjust some of the things you’ve made based on the learning.

All too often, I see people forget the Loop.  First, they put a lot of effort in to Build.  Then, more effort goes into Measure because measuring is hard.  Finally, they study the results and Learn.  But, then they don’t do anything with those learnings.  They forget the Loop!

Gah!

Frankly, if you’re not committed to Loop, then Measure and Learn are a waste of time.  As people who build stuff, we have to be honest with ourselves: are we committed Loop?  If we are, then great!  But, if not, then let’s stop wasting time on Measure and Learn because they’re merely for show…to make us believe that were making data-driven decisions when really we’re just shooting from the hip.

At Cheezburger I kept a wall of sticky notes with bits of wisdom I have learned over the years.  This project gave me an opportunity to walk the talk and live by one of these little bits of wisdom I’ve often shared with others:

Ship First, Develop Second

What that means is that when starting a new project, just write the “Hello World”, then setup deployment process to your production environment, and ship it.  Now, the full pathway from your idea to your keyboard to realizing potential customer value has been paved.  Then, from here on out, things are simple: you’re just doing incremental updates and deployments.

The original sticky note from my wall.

Now, I don’t mean to suggest that you start by creating a robust production environment that can handle massive loads of traffic with redundancy, backups, recovery and monitoring support.  I’m just saying that you need to get your code live to the world.  You want to create something that is apt for the age of the project.

In my case, setting up deployment meant creating an micro EC2 instance, twiddling some DNS settings, configuring a git remote, and installing a handful of packages on the new instance, so that the app would run.  That took me a few hours because I was trying some new things I hadn’t done before, but all-in-all a very modest investment to avoid common pitfalls.  (If the project goes smoothly, then I’ll set up continuous integration, monitoring, etc.)

What are those pitfalls?  Well, this wisdom is contrary to another bit of Lean wisdom: delay effort, work and decisions until the last responsible moment.  In other words, that principle would say that setting up the production environment before a line of code has been written is wasteful.  Yet, there are two mistakes I often see made, and this helps avoid them.

First, developers often spend a lot of time writing code before showing it to potential users.  Part of that problem is that there’s a giant barrier between the work and the users: the setup of a production environment.  This approach puts you a more natural position to show your work and get feedback because it’s ready to be shown from day one.

Second, developers rarely develop as incrementally as they could.  Again, this approach positions you in a really nice way to make small incremental changes, bit by bit.

All-in-all, my point of view is that I’ve seen too many developers waste too much time by writing code that never sees the light of day, or when it does see daylight, doesn’t meet the users’ needs.  Generally, I try to stay lean and avoid waste, but this small bit of premature effort seems worth it.