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. And 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.
Software Developer Consultant vs. Software Developer Grunt
Let me be clear about something, though. When I talk about being a consultant, I don’t mean that you should quit your job and hang out your shingle. You can consult for your own company as an employee, if you so choose. It’s not about employment status or how you collect money. It’s about how you deal with other people.
And this choice boils down to something really simple.
- People come to a consultant and say, “tell me what to do and how to do it.”
- People go to a laboring grunt and say “here’s what you’re going to do and how you’re going to do it.”
If the people who give you your money approach you in the first way, then you’re a consultant. If not, then you’re not. Even if you literally have the word “consultant” in your job title, you’re still not.
It’s all in the interaction.
If You’re Not Consulting, You’re a Commodity
Let’s switch out of the world of software development for a moment. In fact, let’s switch out of the realm of knowledge work altogether to get another look at the idea of consulting.
Let’s say that on my recent cross-country odyssey to San Diego my car had started acting up. Heck, forget acting up. Let’s say that red smoke started coming out of the engine. I’d have gone into a shop in a hurry, and I’d have said to someone, “help me.” In fact, I would have engaged them as one engages a consultant. “In your expert opinion, tell me what’s going on here and what you think I should do.”
Would I have tried to diagnose this myself? Of course not! I’m not a mechanic by trade, and there’s red smoke pouring out of my car. That’s terrifying, and it’s not worth the risk of trying to arm-chair quarterback it in a pinch.
But let’s say something different had happened. Let’s instead say that the top loader on my car had been opened and all of the clothes and stuff I was carrying up there received a good soaking in a rainstorm. And let’s also say that I didn’t have time to deal with this nonsense, having some work to do from my hotel.
Am I going to ask someone for expert advice on this? No, I’m going to try to hire someone on Task Rabbit or whatever to put my clothes in a dryer and do various other tasks. I’m going to give the detailed instructions and probably tend toward micromanagement because I probably understand better than them what needs to happen. I just lack the time.
I’m going to look for an expert mechanic. But I’m going to look for the cheapest labor for my wet clothes.
Juniority and Slow Graduation from Commodity Software Development Labor
Think of someone who enters the software development workforce as a newbie — a “junior” developer. That person has something like 8 different bosses, Bob.
There’s a project manager that prioritizes their work. And then there’s the business analyst that tells them what the software writing needs to do and why (i.e. “requirements”). Of course, there’s an architect who tells them how to write the software, from an abstraction perspective. And then you’ve got a tech lead that reviews their work and supplies more granular detail. And, pretty much every developer on the team with more than 0 experience supplies “how” instructions as well.
This is the epitome of commodity labor, which is why, by definition, it costs the least. The hope, for both this “junior” developer and the organization is that some of those bosses melt away with time and seniority. More people defer to this ascendant developer with time, and fewer people have to say “what” and “how.”
Of course, we, as an industry, have a ready-made narrative for this situation. The “junior” developer doesn’t know enough to be trusted with this decisions. This comes only with time, seniority, general dues paying, and waiting one’s turn.
What Are You Waiting For?
Of course, that’s silly. It’s assumed and unquestioned, but it’s silly. Sure, if you hang around software development shops long enough, getting better at software development, you’ll eventually outlast journeyman idealists and idealists.
But why wait?
Chart a path to people deferring to your expertise as quickly as humanly possible. Become a consultant.
Opportunists figure this out early and that’s why they become project managers or whatever. That’s a much easier path to promotion than competing with a bunch of other commodity laborers that do the same thing as you, but with more experience. But it’s not your only path to promotion. You can carve out other areas of expertise, and technical ones at that. You can become “the build expert” or “the test suite maintainer” or whatever. Find a thing early where no one around you knows as much as you, and you’re on the path to consulting. Continue quixotic, years-long competitions with others, and you’re on the path to commodity.
I have enough for a book in my head fleshing out this topic, so I’m not going to slay it all in a single blog post. Today, you just get the first step. Realize what consulting really, actually is, and realize that you need to do it. The rest will follow, I promise.
Want more content like this?
Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)