Why Every Software Developer Should Become a Consultant

Since writing Developer Hegemony, leaving the traveling consultant life, and spending a lot of time building a content agency, I’ve flailed around a little with what I want to do with DaedTech.

What do I do with this thing, anyway?

I could treat DaedTech as one of Hit Subscribe’s clients.  But DaedTech isn’t really that kind of business.

I could continue to write a series of posts about whatever happens to be on my mind.  Maybe a mix of technical, career, and the like.  But, these days I write more than enough blog posts for our clients to scratch that itch and then some.

So, what to do?

Well, I’ve had plans to build an info product or info products to continue the ideas I laid out in Developer Hegemony.  And more and more people are also asking me about mentoring/coaching/advice in various forms.

But I think all of this is slapping me with analysis paralysis.  How should I structure things with DaedTech to support the eventual vision of whatever it is I decide later to do?

Ugh.  Maybe it’s time to stop with this nonsense and just start creating the information.

I figure I can do it as blog posts, maybe in a series.  If that goes well, world will spread, people will find it valuable and the revenue thing will happen somehow.  Lead with value, and all that.

The Career Empowerment Prologue

So let’s do that.

And to start, I’ll give you what would have probably preceded chapter one in the book idea that I’ve toyed with about how to empower yourself in your career.

Think of this as the prologue.  And the prologue of how to become a consultant involves explaining why I think you should.

I don’t mean that some of you, maybe should, if you feel like it.  No, I mean that everyone who counts him or herself a programmer, software engineer, software developer, or whatever other strange titles we give ourselves, should be a consultant.

Now to qualify that statement, I need to explain what I mean by “consultant.”

As I’ve discussed before on this blog, the term gets truly mangled in our industry.

• A lot of people think that it means a software developer that writes code for a company other than their employer.
• Some think it means you come in, hand wave and spout buzzwords, and leave before anyone can figure out if you’re helpful or not.
• And still others think it’s sort of a black belt of soft skills kind of deal.

But it’s none of these things.

Instead, being a consultant means something much simpler.  It means that you provide expert advice in exchange for money.  And every one of you code-slingers out there should do exactly that.

Read More

Become a Software Specialist with the Help of Your Resume

One of my aims with this blog is to help software developers take charge of the business of writing software.  And, while I love writing rants and diatribes, doing this requires a good bit of positively focused how-to sorts of things.  Today, I’ll charge at one of those: how to become a software specialist in a world of low status generalists.

To specialize, you need look no further than your resume.

But I’ll come back to that in a bit.  First, you need to understand the essential sales problem of the software developer, from a labor perspective.

Individual contributor software development is a terrible business model!

Before you pick up the pitchforks and torches, hear me out.  I realize you’ve earned a good living writing code for some product company or agency.  I’ve done that too in my life.

You can earn a good living this way.  But you can’t really conduct good business this way.  So when software developers hang out their shingles after years of salaried employment, things can go sideways from a leverage perspective.  Mostly, people in this position become contractor staff augmentations that look a lot like employees.  Why is that?

It’s because of an incoherent value proposition: selling code-writing-labor.

To make money as a business-person, you need a customer.  I don’t mean a nameless, faceless corporation.  I mean a middle aged guy named Stan.  Or maybe a hard charging woman in her early thirties named Ashley.  You need a buyer, represented by an actual human persona that you can picture and speak to.  And this person has to be able to afford your services.

Who is this person that can buy tens or hundreds of thousands of dollars of your labor?

The Case of the Split Persona

At this point, you’re probably picturing Stan as an architect or Ashley as a tech lead.  But those people don’t have tens or hundreds of thousands of dollars.  In terms of company money, they have zero dollars and zero cents, unless the company gives them like a $1200 per year training budget.  That doesn’t buy a lot of your app dev, does it?

You want a 3 to 12 month app dev gig, which goes on the market for $50,000 to $200,000.  Do you know who signs off on buying that?  A director named Sheila.  And do you know what Sheila will say if you come to her and tell her that you’re really looking to work on a Node.js-this and a React-that?  She’ll tell you that you need to talk to someone that reports to someone that reports to her.  She can’t remember their names off the top, but, you know what, just send your resume to HR or something.  (I’ve written more on this here.)

When you try to sell a keyword-heavy resume as your value proposition, you create an existential conundrum for yourself.  The people that understand what you bring to the table can’t afford you.  And the people that can afford you can’t conceive of what problem you purport to solve.

The only way you can make sales is to sell to a system — an algorithm involving various people and committees and whatnot.

And that’s a recipe for either going out of business or floating along through your “consulting” career as a pseudo-employee.

Read More