I originally posted this on my blog a little under two years ago. If it's interesting to you, I post new content on daedtech.com roughly weekly.

A couple of weeks ago, I wrote a post in which I announced a new flavor of posts for DaedTech.  I was going to do this as a book or video product, but I tired of analysis paralysis.  So I've decided to just start teaching anyone reading the tricks to becoming a consultant. (Follow along with a new category).  This is the second post in that series, and it concerns your positioning strategy.

Figuring out your positioning strategy should be the very next thing on your list after figuring out that all software developers should become consultants.

If you just said, "wait, my what?" don't worry -- I'll get to that.  But first, a bit of tough love.  I have a tactical rant lined up before I can get back to being helpful and upbeat.  It's for your own good.

The Harsh Truth about Your Current Positioning Strategy

If I ever turn this "from developer to consultant" series into a book or something, I'm not sure if this post from last week will make it or not.  It's not specifically related, but I'm going to build on it here today.

The Craftsman Positioning Problem

In that post, I talked mainly about our industry's bemusing fetishizing of medieval craft guilds, and about how letting yourself get sucked into that trap hurts your career.  Toward the bottom of the post, if you'll recall, I began to talk about positioning.

When you position yourself as a "craftsman," you're boasting about superior quality, but competing with cheaper prices.  People who do this fail to understand why people pay them.  But, in all honesty, self-described craftsmen aren't even the worst at this.  The entire journeyman idealist set gets it badly wrong.

The Broader Developer Positioning Problem

We as software developers, enabled by opportunists around us, cheerfully ignore the real reason that people pay for us.  It's fun for us.

We go to sites that let us "joust" or "duel" or "ninja each other" for badges and tokens and stuff, demonstrating that we can write a sorting algorithm 0.01% faster than the runner up.

And then we think that's our value proposition to employers.

"Why should I hire you?" a non-technical hiring manager might ask.  And you might respond, with something that, in his brain, translates to, "I keyboarded in the stuff with the things and it was 4 nanoseconds faster than the what's-it by the other guy."

And then you think that helped you land a job.

If you make $100,000 per year, you might look at a "more senior" developer making $130,000 per year and assume that she's 30% more awesome than you.  If you suddenly discover that she only knows 4 GOF design patterns off the top of her head to your 14, you might then start railing about the injustice of it all.

The industry meritocracy has failed!  (But not systematically and in a way that invalidates algorithm jousts -- just totally in this one isolated case!)

Here's the thing, though.

To your employer, assuming the employer is larger than "tiny" your two salaries are an inconsequential rounding error.  $100K is $50/hour and $130K is $65/hour and both of those rates line up with low end US contractor talent or good offshore talent, if they're looking for geographic arbitrage.

They're not hiring you because you're "better" at code jousting.  They're hiring you because you're the fungible person with the desired citizenship/work status that the interview process spat out the other side.

Positioning Expert Beginnerism

Why am I harshing your mellow here?  It's because when you heard "positioning strategy" you probably assumed yourself to be a complete novice (or else that you were decent at it).  But you're neither of those things.

Instead, you're a guitarist that learned terrible technique and now has a longer path than someone who had never touched a guitar.  Or maybe like a younger Erik with his bowling game -- like an expert beginner.

You've had your ups and downs with the interview process, but more ups than downs.  Across a few companies, you've secured a six figure salary and the "senior" designation.

This happens because the powers that be recognize your talent and pay you, right?  Because you successfully position yourself in the upper quintile of all software developers, right?

And if this same process also hires brilliant Paulas at an alarming rate, you just kind of ignore that... uh, right?

How Positioning Works for You Today

Now, you do wind up in your role and others don't.  So something has to uniquely position you.  But you think it's your impeccable resume full of acronyms and the grand meritocratic thinning the herd of applicants.

But, here's how it really goes from the other side.

Ugh, I have like 1,000 resumes here.  What a mess.  Let's just eliminate all the ones that didn't come from Teddy's Tech Recruiting Emporium because I like Teddy.  Alright, down to 50.  Better, but still a pain.  Let's filter out anyone with no Javascript and with less than 5 years of experience.  Alright, 10 resumes.  Now we're talking, but one more slice -- let's stipulate that they have to be local candidates because meatspace.

3 left, so we'll interview them (which is the more or less the same thing as choosing randomly).

So you think you position yourself with badges, elbow grease, passion, and skill.  But, in reality, others position you with networking, resume keywords, years of experience, and geography.

That reality is a little depressing at first.  But, that's okay, because you'll soon realize that this is much better than the world we want to believe in -- a comically stupid one in which 20 million people all try to position themselves as "leet coding generalist."

Positioning from First Principles

Finally, we're ready to talk positioning, and then subsequently, positioning strategy.  Hopefully you now see the reason I've spent so much time ranting here.

The default software developer view of the world is to badly misunderstand how positioning works, and to assume we must be doing something right because we earn good money and because it's nice to think that our hard work and general awesomeness earn us rewards.

But get that out of your head.  Stamp it, and kill it.  And let's start from scratch.

First of all, what is positioning?  Well, you could easily find a Wikipedia definition or similar, so I'll summarize with a composite of what you'll find googling.

Positioning is how you differentiate yourself from competitors.

In both Developer Hegemony and in a talk I gave recently, I encourage anyone employed to start thinking of themselves as "a company of one."  This means that other software developers, even your buddies, are your competitors.

So you need to think about how you differentiate yourself from them, and you need to think of something that beats "better at programming," which is more or less unknowable by anyone, let alone those who sign checks.

In this series, I'm going to talk about becoming a software consultant long before you ever go off on your own.  So, I'll refer to this gainfully employed, aspiring consultant as a "stealth consultant" from here on in, because I find that term amusing.

And, if you're a stealth consultant, you need to establish a positioning strategy before you do anything else.

Starting to Grok Positioning Strategy

Believe it or not, when you're an in-demand consultant (not of the stealth variety), you spend more time trying to talk people out of hiring you than into hiring you.  Getting to the point where this bit of judo makes economic sense is no easy feat and, admittedly, an advanced topic.

But, hey, when you're a stealth consultant and learning how to do this stuff, you don't need to worry about paying the mortgage.  So you can learn and practice this dynamic, consequence free.

And you do this by getting comfortable with what Jonathan Stark calls the why conversation.  This is a conversation where you either help them see a better alternative to going with you as an expert or you show them that you're the best and only option.  You ask them questions.

• Why not hire someone else instead of me?
• Or why not pursue a different project/goal?
• Why not use a different approach?
• Why not just not do this at all?

In and of itself, these questions just make for good discovery, and they make sure that the client isn't ill-advised in hiring you.  But they also get you to the root of positioning in a hurry.

What is positioning strategy really about?  It's about maximizing the number of why conversations you can ace.

Or, in other words, it's about making it hard for anyone to talk people out of hiring you for your expertise -- about making you a no-brainer.

Positioning Strategy Counter Example: The Senior Software Engineer

To see this in action, let's first look at a counter example.  Hopefully how you'll see why I ragged so heavily on the positioning of software developers.  Imagine the why conversation happening in earnest between you and some dev manager (if both parties were being honest).

• Why not hire someone else instead of me?
  • We tried, but our first three choices hired on elsewhere and, between you and the other guy, it's really a coin flip.
• Or why not pursue a different project/goal?
  • A different "project" than generic app dev?  Because we're the generic app dev group.  What else would we do?
• Why not use a different approach?
  • To hiring?  I dunno, that's mostly up to HR.
• Why not just not do this at all?
  • Because Jessica quit and I have to backfill her.

Positioning Strategy Actual Example: The Stealth Consultant

I'm going to continue an example from the first post in the series, but I'll clarify a point based on the comments in that post.  This example assumes that you work in a group where they don't have CI/build automation and that nobody really knows how to do it or will start arguing with you about it if you try.

If people were to argue with you, you need a different specialty -- different positioning -- because "why not someone else instead of me" goes out the window.  This heuristic will actually help you a lot as you ponder your positioning.  It can't be something where the dev manager says, "sounds great, but ask [insert expert beginner here]."

So, let's take the example of someone getting good and developing expertise around CI/build automation.

• Why not hire someone else instead of me?
  • Nobody else here knows how to do this, and it's too expensive to bring in an outsider.
• Or why not pursue a different project/goal?
  • Our manual builds tie up people for days and deployment mistakes are hurting our reputation.
• Why not use a different approach?
  • If you know of a better way to fix an error prone/expensive deployment pipeline, we're all ears -- you're the expert.
• Why not just not do this at all?
  • It's 2018, and we look increasingly ridiculous not automating this stuff.

Reverse Engineering the Why Conversation

I went through that above example to, hopefully, start to make things tangible.  But the real goal here is to get you thinking about perfect why conversations.

Positioning is about imagining yourself having why conversations that go perfectly -- that couldn't result in anything but a client paying for your expertise.  Getting to that point isn't easy, and examples can only take you so far.

At its core, positioning is about reverse engineering this conversation.  What would have to be true of you, your experience, and your area of focus to have a conversation like this?

What is a set of differences between you and everyone else that make you uniquely qualified to weigh in on something as an expert and set strategic direction?

• Are you the only one that understands or has researched this thing?
• Is everyone else who might help too busy?
• Can you make the business case for it better than anyone else?
• Do you have fresh perspective, uncolored by having skin in the game?

As you can see, there are innumerable ways to picture a successful why conversation and work your way back to your current or aspirational skills.

But do keep one thing in mind.  You must have this conversation with a human buyer.  So knowing more than anyone else about some really specific piece of technical minutiae won't work.  The kind of person that will make decisions about (pay for) consulting expertise isn't the kind of person that will understand what you're talking about with that.  Your buyer (probably a manager) must grok your positioning.

The Ways You Can Position Yourself

With the broader goal and positioning strategy in mind, let's talk tactics a bit.  How do you make yourself stand out?  What are the ways you can differentiate yourself from others?

Well, let's start with the obvious.  Journeyman idealists differentiate themselves on the basis of price while claiming to differentiate themselves on the basis of quality.

So, you can, obviously, differentiate on the basis of price and quality.

That said, the former is a recipe for commoditization and it undercuts a consultant's credibility.  And the latter is both nebulous and often nonsensical in the realm of expert advice.

So let's look at some other ways that you can position yourself as a consultant or a stealth consultant.

• Focus on a specific target market/client (e.g. focus your expertise specifically on serving the HR department).
• Geographically (e.g. you're the only person in the Hoboken location with skill X)
• Niche/focused skill (e.g. you're the only one that knows anything about the Salesforce API)
• Methodology (e.g. you discretely and privately furnish advice to leadership about subjects where their lack of knowledge would make them look dumb)
• Offer unique benefits (e.g. nobody else in the group produces unit tests in addition to delivering features, though this is more delivery than expertise)

I could probably go on, but hopefully the gears are starting to turn.  And you're not limited to one of these tactics -- you can mix and match.  The thing you need to do is get yourself into a position where (1) you offer unique, authoritative expertise and (2) someone wants to take advantage of it.

Now, Get To Work

This would serve as a conceptual chapter 1 in the book, if I were writing it.  (Or maybe chapter 2, if the prologue were chapter 1.)  We're not going to solve all of the world's problems in a day, and you haven't magically gone from "staff software engineer" to consultant by reading this.

But it's a start.

You're going to mull this over, try some things, and look to figure out how to establish yourself as an authority without trying to out-senior the expert beginner with 20 years at the company.  But you might struggle, and you might not be far enough along in your path for your management/coworkers to regard you as authoritative in anything.

Don't let that stop you.  That's not an obstacle -- it's a reading and study list.  While everyone around you goes onto code-jouster-ninja websites to try to position themselves against 20 million other generalists, you, unlike them, are picking the next thing to learn on the basis of improving your positioning.

Don't get me wrong -- as a technologist, you need to learn to program well enough to do a professional job.  But you don't need to waste your career tilting at the windmills on the joust site.

So think about your positioning strategy.  Think about what will improve it, and put that on your reading/Pluralsight list next to the obligatory generalist stuff.

And, congratulations -- you've just taken the first step away from commodity labor and into consulting.

If you'd like to ask a reader question, you can do so at the "ask me" page.