DaedTech

Stories about Software

By

Value Proposition Guidance for Recovering Programming Generalists

I saw something awesome earlier this week.  Because I’m in the content business, I was trying to explain the concept of “pain, dream, fix” to a client.  It’s a way to write landing pages that focuses on customers and their pain points rather than on product features.  Anyway, in looking for a good explanatory link, I found this gem from Anton Sten.  It’s great advice for landing pages, full stop.  But I’m going to build on it to offer you advice about your value proposition.

Getting a value proposition right is hard enough.  But when you’re used to being a software developer, it’s almost impossible because of how badly everyone teaches us to get this wrong.  So let’s look at the bad advice we get so that we can then start with first principles.

Here’s the picture from the gem of a post I found.  Let’s start there.

The Basics of Pain Dream Fix and the Value Proposition

About a year ago, I wrote about how to start freelancing/consulting as a software developer.  In that post, I emphasized the idea of a “who and do what” statement.  This is a mad lib that takes the form of “I help {who} do {what}.”  This is a value proposition — a way to convince prospective buyers to buy from you.

In the software world, we constantly get this wrong.  And this image illustrates perfectly how we get it wrong.

We tend to talk about our products in giant lists of features.  Or we sell ourselves as an alphabet soup of skills and tech stacks.  And, in doing this, we completely neglect to mention who should care and why.

“Pain, dream, fix” (and this picture of Mario) is a way to jolt ourselves out of our professional solipsism and to start thinking of others.

  1. Pain: Poor Mario is too small and weak to survive in a world of Goombas and Koopas.
  2. Dream: But he could be twice the size he currently is and able to slay his enemies with flamethrower arms.
  3. Fix: All he has to do is eat this flower.

Flower provider value proposition:  We help undersized plumbers kill their foes by giving them super powers.

Seems simple.  But we really manage to get this comically wrong.

Read More

By

Positioning Yourself to Coworkers as a Stealth Consultant

In a nod to yesterday’s announcement, I’m going to demonstrate how just unaltered the DaedTech blog might be, content-wise.  To wit, here’s a both that qualifies in both my reader questions series and my “developer to consultant” series.  This makes sense, since it’s a question about the developer to consultant series.

Today I’ll talk about positioning yourself as if you were an independent consultant, but with the caveat that you’re trying this out on your coworkers.

Positioning Revisited, But Internal to a Company

When it comes to posting on this blog, I love not having to make the caveat that my opinions aren’t my employer’s, or whatever.  The more used to that I’ve become over the years, the fewer punches I’ve bothered to pull.  And so it went with my first developer to consultant post.  In that post, I unapologetic declared that every developer should become a consultant.

If I were writing a book, that post would have been the prologue.  Chapter one, then, would have been this post about positioning.  It’s a long read, but I recommend it for understanding the nuance of positioning.  At the 10,000 foot-iest of 10,000 foot views, your positioning is your plan to ace the question, “why should I hire you, specifically?”

The reader question came in the comments of that post.  And here it is.

For an employed software engineer, what are some of the ways to “signal” your positioning strategy? In other words, how do you let the org/team/manager know what your unique value prop is? I’d love to get your thoughts on this.

This is an interesting thought exercise, because to participate in the standard hiring process is to have the worst possible positioning strategy.  When you do this, you’re saying, “I’m slightly better than dozens of otherwise interchangeable resources whose resumes you’re holding, so hire me.”  To have a good positioning statement as a consultant is to say “I’m the only person that can deliver X for you in exactly the way you need.”

So today’s topic is about how to develop the latter flavor of positioning strategy in the former world.  But who am I to shy away from nuanced topics?

Read More

By

Stop Arguing with Software Developers on the Internet

I won’t bother pasting the iconic XKCD that we’re all thinking about right now, given the blog post title.  Instead, I’ll just lead with the premise.  You should stop arguing with software developers on the internet.  In fact, you should probably stop arguing on the internet altogether.

Now, before you go any further, notice that this is a post in my “developer to consultant” series.  What follows is thus advice for someone who is looking to be a consultant — someone for whom an internet presence is a marketing asset.

If that doesn’t apply to you, then don’t worry.  If all you’re looking to do is find some catharsis because the expert beginner serving as tech lead in your group has outlawed writing unit tests, then go nuts.  Pick every fight out there on Reddit and in comments sections.  Sharpen your reasoning or debate skills by bouncing ideas off of other people with varying degrees of mutual hostility.  Do you.

But don’t kid yourself — what you’re doing is a hobby, not a hustle.  It might be fun, and it might help you in a vague way, but it hurts you professionally (unless you’re doing it in a very calculated fashion, but this is an AP tactic I’ll return to).

Arguing on the Internet as an Employee is a Lot Different than as a Consultant

When you’re an employee, the internet is sort of a vast sea of potential fights to pick.  You can argue with your cousin on Facebook about politics for a while.  Then, you can mix it up by posting an angry screed to Medium entitled, “[Thing Everyone Currently Likes] Considered Harmful.”  And finally, maybe a few palate-cleansing down-votes on a Stackoverflow before you call it a day of sometimes doing your work.

As long as your Twitter handle contains some boilerplate about how your views aren’t the company’s, you’re mostly good.  From there, you really just kind of need to avoid being overtly offensive when people can trace your words back to you, and your company will just shrug off anything you do.  You play in a vast yard, and the only thing that will trigger your metaphorical shock collar is running outside the generous boundaries of “reflecting poorly on the company.”

Not so when you own your own career and brand.

When you own your own career and brand, your presence on the internet becomes a digital job interview, writ large and made permanent.  As an employee interviewing for jobs, imagine your interviewer being wrong about something.  You’d bite your tongue, turn slightly red, hemorrhage a bit internally, but ultimately keep the indignation to yourself.  When you go on your own, you should approach your online presence this way.

To really underscore why, let’s place you in the role of a buyer through an analogy.

Read More

By

Consulting Skills You Need, Without the Vague Platitudes

Let’s take a break from the heretofore linear nature of the developer to consultant series.  I’d been writing this as if it were a book.  But it’s not a book (yet).  So today, appropos of little, I offer my thoughts on essential consulting skills.

Now, before you object with, “I just want to be a software developer,” read this post about why every developer should also be a consultant.  If you want your career to consist of more than having project managers order you around, you’ll need these skills.  They’re essential skills for consultants, but they’ll help your career either way.

I poked around a little to see what others had to say on this subject.  If you google “consulting skills” you’ll find advice that comes in two flavors.

  1. “Here are some skills you need to convince Gigantic, Ubiquitous, & Inevitable Consulting, Inc. to hire you as an entry level consultant.”
  2. “Here are some skills you need as a consultant, like being nice and having curiosity.”

Let me briefly address these things before I offer my obviously different take on the matter.

I Have No Idea What To Tell You about Consulting for Massive Consulting Shops

What does it take to work at one of these huge agencies?  Dunno.  I’ve never done it.

So if you’re looking for interview advice ahead of your phone screen with McKinsey or PWC, you’re probably barking up the wrong tree.  Will these skills help you in general?  Yeah.  I don’t see how they couldn’t.

But this advice is about how to succeed with your own, specialized practice.  It’s not going to help you get an entry-level, salaried consultant position.

No Vague Platitudes Here, Just Consulting Skills

Let’s be clear on something.  “Be nice” isn’t a skill.  “Enthusiasm” and “curiosity” aren’t skills.  These are all more or less personality traits.

But I’m not objecting based on semantics as much as I am on the basis of effectiveness.  In the “every developer should be a consultant post,” I laid plain the definition of consulting.  It means you provide expert advice in exchange for money.

Now, does being nice help with that?  Or curious?  Yes, of course it does.  But so do a lot of other things, too, in a vague way.  Decent hygiene, taking notes, and not showing up drunk are also helpful.  But these aren’t skills, and they’re not specific to succeeding with a consulting practice.  Most of this is just table stakes for existing in the corporate world.

So I’m making a point here to leave out ‘skills’ that are too vague to help, like “good EQ” or “leadership” or whatever.  Instead, I’m going to list some very specific things that you can actually practice.  And I’ll list them in rough order of when they help in a gig, from discovery to wrap-up.

That said, let’s get specific.

Read More

By

Learn from My Mistakes: Applied Positioning and Specialty Lessons

I’ve talked a lot about how not to position yourself lately.  Last week, I suggested you not do it by tech stack of framework or whatever.  And before that, I suggested you not do it by being a laborer.  In general, I’ve talked a lot about positioning lately.

But all of the talk has been pretty abstract.  Let’s switch it up today and get concrete.

Up to this point, I’ve thrown out off-the-cuff examples, like becoming “the build expert” or something.  Some of you have asked for more tangible, specific examples.  And I can actually think of no better way to offer those examples than by wandering through my own career, looking for them.

Of course, I didn’t figure all this stuff out until quite recently.  So these are all “road not taken” kind of examples, and that’s why I’m titling this post “learn from my mistakes.”  Here are all the times that current Erik would have told past Erik to recognize opportunity knocking.

Read More