Category Archives: JTBD

Recruiting Passively Looking Developers

This is the second in my series at applying Jobs-to-be-done (JTBD) techniques to Recruiting. To recap, our open job position is hired by applicants (gets a job done in their lives) and has hiring criteria that the applicant applies when making decisions about it.

In their JTBD training, Bob Moesta and Chris Spiek teach how to interview to understand the JTBD Timeline (here’s a great description of the JTBD Timeline from Ross Belmont and here’s Bob and Chris’s JTBD Timeline Diagram). In this post I want to concentrate on the beginning of the timeline — the part where someone has the first thought that they might switch and up until active looking.

I believe that that the vast majority of excellent software developers are not actively looking for a job. Back in 2007, Joel Spolsky put it this way:

From a recruiting perspective, the problem is that the people I consider to be in the top 1 percent in my field barely ever apply for jobs at all. That’s because they already have jobs. Stimulating jobs. Jobs where their employers pay them lots of money and do whatever it takes to keep them happy. If these pros switch jobs, chances are the offer came through networking, not because they submitted a resumé somewhere or trolled a job site like Monster. Many of the best developers I know took a summer internship on a whim and then stayed on. They have applied for only one or two jobs in their lives.

If you want to run a world class development team you need to internalize this. What would you do to your recruiting efforts if you wanted to hire people that aren’t looking for a job?

Here are a bunch of things that won’t work at all

Advertising on job sites
Tweaking your “Company > Careers” page
Hiring headhunters (despite the hunter name, they are usually gatherers)
Tweeting, Updating Linked-in statuses, etc.

It’s fine to do these things — there are actually active job-seekers. But, if you look at typical recruiting, this pretty much sums up the entire effort.

Also, targeting the passive lookers is a long-game. If you need someone right now, then traditional recruiting is your best bet. But, in the long run, if you know you need a steady stream of applicants to succeed, you have to have a plan to target passive lookers.

Here are some examples of what others do;

In the link above, Joel’s solution is an internship program. Not just any one — he treats it like the critically important company building tool it is:

I send a personalized letter to every promising computer science major that I can find. Last year I sent 300 letters to fill six intern positions. Not e-mail. My letters are printed on a real piece of Fog Creek letterhead, which I sign myself in actual ink. Apparently this is rare enough that it gets kids’ attention.
Matasano Security is “always hiring security consultants. Really.” In order to help build a pipeline of passive developers who know they exist and what they do (and that they are hiring), they have a “Crypto Challenge” email campaign. When you sign up, they email you list of crypto coding puzzles. They don’t recruit through this e-mail, but if know Matasano at all, you know that they are always hiring.
I work in developer tools, so I know that our marketing department is always talking to developers (hey, we’re hiring a Developer Evangelist to help us do that even better). If you market to developers, you should have a plan for making sure they know how great it would be to work for you. If you don’t, but you need to hire a lot of developers, adding an SDK product to your line-up is not a bad idea (it’s probably a good idea anyway — the software business is all about platform proliferation).
You absolutely need to have a functioning referral program — almost everybody has something, but if you aren’t getting a significant number of leads this way, you need to be having a tough conversation with your developers about why they wouldn’t recommend that others work with them. The answer is NOT that the referral program doesn’t pay enough, but you could probably make it work if you overpay.

I believe that #4 is your indicator that you have solved the JTBD for recruiting (which is that the product is right — your developers love their job and would recommend that others with them). Look at the end of the timeline I linked at the beginning of this post — it ends with satisfaction (or not), and the point of that is repeat business and word-of-mouth.

Apply Jobs-to-be-Done (JTBD) to Recruiting

Jobs-to-be-done (JTBD) is a theory for what causes us to buy things. The quick description is: jobs arise in our lives and then we hire products or services to do them. The key insight is that the job attributes should be used to guide product development, not the customer attributes. Here is Clay Christensen describing the concept if you haven’t heard it before.

This theory was publicly introduced in his book, The Innovator’s Solution, but is being popularized by Bob Moesta and Chris Spiek in Switch Workshops and soon at the Business of Software conference.

I was lucky enough to participate in some training with Bob and Chris, and so I often think of Jobs theory whenever I wonder why people do anything, and recently I’ve been thinking about recruiting (yes, Atalasoft has a job opening for a software developer in our marketing department to help evangelize our products).

Now, when hiring we naturally think of the job we need done, and of course, we are explicit about that when writing the ad, evaluating resumes, interviewing, ultimately hiring someone. The job has hiring criteria and we use it.

But, at the same time, potential applicants also have a job-to-be-done in their lives, and they are judging us with hiring criteria. In this case, we usually fall all apart. We try to write job descriptions that sell ourselves too, but, frankly, I’m not sure they actually address the applicant’s criteria.

In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.

I’m sorry to say that I haven’t done this, so I don’t really know what needs to change.

In any case, I’m going to be thinking and posting more about this — hopefully trying it in practice. In the meantime, if you are a web programmer (preferably in .NET or Java), have at least 5 years of experience, and you want to work in a developer tools company’s marketing department, creating technical content (demos, blogs, articles, sample code, tutorials, brochures, etc) to help developers learn more about our products, get in touch with me. At Atalasoft, you’ll work with smart and hard-working colleagues, where we have an enormous amount of respect and trust in each other. Some of the best programmers in Western MA have chosen to work here, and we can’t wait to meet you.

Making progress with clojure

In the Jobs-to-be-Done framework, we think of products as being hired for jobs that arise in people’s lives. This gives us a way to design the product around the hiring criteria.

To practice thinking more this way, I’ve been analyzing products that I consume using the tools that I learned from Bob Moesta and Chris Spiek from the Rewired Group.

The first tool I used is the the progress making forces diagram

This diagram is used to understand the forces that are at play when a consumer seeks to make progress (by purchasing a product or service).

Each force is unpacked and discussed in detail:

The Push of the Current Situation

The Pull of the New Solution

The Anxiety of the New Solution

The Allegiance to the Current Situation

I am working on developing a back-end to my iPhone app, PaleoViz, and the web stacks I am most comfortable with (Django, ASP.NET and J2EE) are all not ideal for what I want to do.

The push from my current situation is composed of these sub-forces:

I want to deploy on either Heroku or Amazon Web Services, and ASP.NET is expensive or not supported
I don’t really want to go back to using J2EE for anything. I am most familiar with pre-RoR inspired frameworks, so I would have to learn something new anyway
I am concerned that what I want to do isn’t right up Django/Python’s alley

The pull to clojure is

I’ve been wanting to learn it
The web frameworks seem to be similar to what I like about Python, but deploy to a JVM

My anxiety is

clojure is quite a bit different from what I know
Although Java libraries are available, clojure-native ones seem comparatively immature or non-existent

My allegiances

My only real allegiance is to Django/python which I know would probably be “good enough”

The reason for the product designer explore these forces is that ones that come up again and again need to be addressed in the product or its messaging. The first two forces start to define a competitive advantage/differentiation that should be accentuated.

As a consumer, this exercise adds some rationality to a process that probably wasn’t all that rational during the consumption. I’ve been keeping an eye on clojure and waiting for an opportunity to play with it. You can see that in my “I’ve been wanting to learn it” bullet point — that is something that needs to be unpacked to get at the job I am hiring clojure to do.

What is the Jobs to Be Done Framework

I recently have become interested in the Jobs-to-be-done framework outlined in The Innovator’s Solution by Clayton Christensen. To start to apply it at Atalasoft, I wrote this blog about how an SDK’s job might be understood and described the framework this way:

Briefly, you look at a product as the job it was hired to do, rather than its category, features, benefits, who bought it, etc. Christensen makes the argument that jobs are enduring over time (as products and customer segments change).

and concluded:

Applying this insight gives SDK makers a way to target features, not at just the job the SDK does for their developer customer, and not just at what their application does, but also at the job that the end-user is trying to do.

Today, I was sent a quora link where the JTBD framework is being discussed. I’m looking for JTBD tactics, so I loved this part from Chris Spiek:

If we were doing jobs research around the Starbucks offering, it would start with something like: “tell me about the moment when you first considered going to Starbucks. Where were you? What were you doing? Who were you with? What time of day was it?” The interview would move through the decision making process (what else did they consider?), the consuming process (being at Starbucks), and the end with “looking back” and understanding their concept of value (what it did for them) upon reflection.

By conducting a number of these interviews, you can begin to see “jobs” emerge.

To see an example of jobs being discovered and filled with Social Media sites, read Whitney Johnson’s What Job Does Social Media Do?

If you hire social media, especially to promote your business, you will likely have your own reasons, but ask yourself the question, “What problem am I trying to solve?” This will likely get you to the functional element. To peer into your emotional and social why, also ask “what progress am I trying to make?”

These are all great starting points to getting to know JTBD — I will be posting much more on this to help myself learn more about it.

Making an SDK Better at its Job

Clay Christensen’s The Innovator’s Solution [amazon affiliate link] describes a way think about products, called the jobs-to-be-done framework. Briefly, you look at a product as the job it was hired to do, rather than its category, features, benefits, who bought it, etc. Christensen makes the argument that jobs are enduring over time (as products and customer segments change).

His example is a chain restaurant looking to increase milkshake sales. After using traditional methods and failing, they set out to discover the job that milkshakes are hired for. Here’s Christensen’s account:

The key thing here is that they found a customer segment (morning commuters) that would never have been defined beforehand. Also, the metrics that commuters considered important (long-lasting, quick purchase, fits in cup holder, etc) were nothing like what they would have asked (level of chocolate, healthiness). Jobs-to-be-done points the way to the right innovations for a product to be a better employee at the job it was hired for.

Of course, I want to apply this to Atalasoft and our .NET Imaging SDKs, but SDKs are a weird case. They have to do the job that our customers’ customers want to do (we make tools for toolmakers). If I look at only our customers, I will see jobs that don’t get to the root of the problem.

In this table, the first column is something DotImage does, the second is something that the application using DotImage might use that for, and the final column is the job being done by the user of the application.

SDK Job	Application Job	User Job
Turn a Code 39 Barcode into text	Take a 1000 page TIFF and split it into many documents based on barcodes	Scan a pile of paper as one document, but have the software know how to split and import it automatically
OCR a TIFF and produce a PDF with text	Scan a document and build a search index of the text in it.	Find all documents related to a specific customer to comply with an e-Discovery document request.
Scan a document from a website and view it	Import a scanned document into a repository	Provide ID and other documents when signing up for a bank account
Annotate a document	Provide a document collaboration workflow	Ask a question about a specific line item in an invoice.

As you get more to the right side of the table, you start to see enduring jobs – 100 years from now, you’ll have to show ID when you open a bank account, and invoice discrepancies will need to be resolved, and the same was true 100 years ago.

Applying this insight gives SDK makers a way to target features, not at just the job the SDK does for their developer customer, and not just at what their application does, but also at the job that the end-user is trying to do.