September 19, 2017

Two tales of Alice

Thanks to everyone who sent in thoughtful and detailed replies to my recent messages about vertical vs horizontal vs platform specializations. Most of the replies boiled down to sentiments like:

I hear you and I recognize that these points all have merit. I’m the first person to admit that there are exceptions to virtually every guideline I present here on the list.

When I’m working directly with a student, it’s not uncommon for them to posses some unusual capability or trait that causes me to make an exception to my stock advice.

That said, let me describe what I see over and over again with students who are specializing for the first time. I’m going to do so by telling you about how the two most common types of specialization might play out for a web developer named Alice.

Two tales of Alice

For the sake of argument, let’s say that Alice is a generalist full-stack web developer. She’s got a working knowledge of AWS, LAMP, and Rails. She considers herself primarily a Rails developer and makes a living building custom Rails apps for clients.

Alice only gets about two new leads per year. This scares her and she knows she ought to do some marketing to increase that number. She’s tried a bunch of random marketing tactics in the past like social media, blogging, SEO, PPC, and so on, but none of them ever amounted to anything.

The two most common ways that Alice might choose to specialize are:

Here’s how each might play out...

1) Vertical Specialization

Alice likes yachts so she arbitrarily decides to specialize in building web sites for companies that organize boat shows. She does a Google search for “list of boat show events” and gets 28M results. The first page is chock full of options like:

With five minutes, she has a list of 50 boat shows.

Within an hour, she has contact information for all of the companies who organize boat show events.

Within a day, she has contacted all of the boat show event organizers on her list asking if they could help her out with a quick research call.

Within a week, she has five calls set up.

Within a month, she has learned what she services she can offer that will be of value to boat show event organizers, and the language she needs to use to market and sell those services to them.

Within a year, she has worked with three boat show event organizers and is starting to feel a level of expertise in serving her new vertical.

. . . .

Of course, it’s true that things might not work out as perfectly as I’ve described here.

It might turn out that boat show event organizers don’t need anything that Alice can provide with her generalist full-stack web developer skills.

At which point she can pick a different vertical and try again.

2) Horizontal Specialization

Alice likes optimizing the performance of the MySQL databases that power her Rails apps, so she arbitrarily decides to specialize on MySQL performance optimization.

She reads every important book, blog post, and white paper on the subject. She watches all the popular online screencasts, tutorials, and conference sessions. She starts participating in online communities focused on MySQL performance issues.

This takes many hours and probably goes on for weeks or months.

Alice implements what she’s learned in her side projects and starts to feel confident that she knows what she’s doing. She starts to apply her learnings to her client work, whether it was requested by the client or not.

This takes many hours and probably goes on for weeks or months.

Alice starts to blog about her findings and shares her articles on Twitter, in a Rails subreddit, and Hacker News. Her articles are seen almost exclusively by her peers. Some of them share her articles with their peers (except for the Hacker News people, who just argue with her about minutia). The traffic to Alice’s website starts to go up slowly. It’s made up almost entirely of web developers.

This takes many hours and probably goes on for weeks or months.

A MySQL conference organizer is looking for new speakers and starts asking around for fresh faces. A developer friend connects them with Alice. Alice puts together a talk and submits it. After a few rounds of edits, her talk is accepted.

Alice builds her slide deck for the conference, along with a companion repo on Github for interested attendees to play with after the event. She rehearses her talk at a local meetup and feels confident that she’s got it down. Eventually, she presents her talk at conference to an audience of her peers.

This takes many hours and probably goes on for weeks or months.

An internal web developer (let’s call him Bob) who works at a company that organizes boat shows is having a performance problem with their website. Bob suspects MySQL is the bottleneck and stumbles across Alice’s blog after a few Google searches.

Bob doesn’t have the authority to hire Alice, so he explains the situation to his boss Charlotte and tries to get approval to bring Alice in.

Charlotte doesn’t really understand the details of what Bob says (e.g., “MySQL foreign key constraints might be causing full table scan on delete,” or some such) but he seems to think they need Alice for some work on the website.

Charlotte tells Bob to reach out to Alice and find out how much whatever Bob wants would cost. Bob does this, Alice complies, and Charlotte receives a proposal. Charlotte is shocked by how high Alice’s fee is, and tells Bob to get a few more quotes from “more reasonably priced” vendors.

This takes many hours and probably goes on for weeks or months.

Alice is asked to write a MySQL book for O’Reilly. They work out a proposal, a contract is signed, and Alice receives a small advance. She begins writing and submitting chapters.

While she’s working on later chapters, her editor is sending back changes to earlier chapters. Her tech editor keeps finding bugs in her code examples caused by encoding issues that crop up when cutting and pasting from Sublime to Word.

The book goes through final approval, is sent to the printer, and released online and IRL book stores. Alice receives no money from book sales until her advance is recouped.

This takes many hours and probably goes on for weeks or months.

Alice is recognized by her peers as a world-wide expert on MySQL performance optimization. She’s been at it for so long that people who were once her peers are now in upper management at some pretty big startups.

Their companies have tons of cash, they have sovereign control over their departmental budgets, and they know Alice is THE rockstar/ninja/guru for what they need. They contact her out of the blue and are willing to pay a lot of money to get their project on her calendar.

. . . .

Of course, it’s true that things might not work out as perfectly as I’ve described here.

It might turn out that Alice never gets invited to speak at a conference, or to write a book for O’Reilly, or to accept gobs of cash from a hot Silicon Valley startup.

At which point she can pick a different horizontal and try again.

Two differences

The obvious difference between vertical and horizontal specialization is that vertical allows you to find out whether your chosen specialization can be converted into a viable market position in weeks or months, instead of years.

If it turns out that Alice’s vertical specialization was a bad choice, she’s almost certainly going to discover this in the first month with less than 20 hours of effort.

Conversely, if it turns out that Alice’s horizontal specialization was a bad choice, she’s almost certainly not going to discover this until she has spent years and thousands of hours of effort barking up the wrong tree.

A less obvious difference between the two is that vertical is “you focused” (i.e., focused on your clients) and horizontal is “me focused” (i.e., focused on yourself).

The result if this is that with a vertical specialization, you quickly learn:

You might accidentally learn these things with a horizontal specialization, but it’s more of a side effect. If you learn them at all, it’ll almost certainly take an order of magnitude longer than with a vertical specialization.

Please note!

Please note that I haven’t said that you can’t build a profitable business on a horizontal specialization.

What I am saying is that it almost always takes a lot longer to validate a viable market position with a horizontal specialization than it does with a vertical.

If you are dead certain that you will be a horizontal rockstar and you’ve got the swagger and hustle to make it happen, then by all means go for it.

On the other hand, if you are a generalist who wants to specialize but is uncertain who or what to focus on, picking a vertical presents a lot less risk.

Yours,

—J

BackRandomNext