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.
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.)
Thanks a lot for this article. You are totaly right to advice people to start on this path as soon as they can. It’s often a lot easier to devot some time to building a consulting specialty while you are young without family. I should definitely have started earlier. I also found that side projects helped me a lot to learn more on particular topics (http://bit.ly/2lALsZm).
Heh, I love that comic in your post 🙂
I totally get the cartoon
Reading your book, “Developer Hegemony” has changed my thinking completely. I have been freelancing for almost 2 years and decided I would see what is available regarding full-time employment. I now see the hiring game so differently and my answers to questions in interviews have changed from just “stump the chump” style answers to more business-oriented response. I also find myself using the words all interrogators hate, “It depends”. After you start thinking like a consultant you will find that more and more full-time jobs are not a good fit. You go from full-time code slinger to someone who values… Read more »
That’s interesting, to hear about how it affects you from a job interview perspective. Do you find that you’re better at steering interviews away from stupid games, or is it more that you’re just better/more qualified at using the interview to filter out companies with amateur hour hiring processes?
Another great article, but when I read the words “You can become ‘the build expert’ or ‘the test suite maintainer’ I almost shouted “NO!” aloud to my screen. Those are inwardly focused and affect the bottom line in an extremely indirect way–nobody outside the dev group is going to know or care. It’s not going to get you positively noticed by anyone who matters, and it’s probably going to devolve into a losing pissing match between you and your longer-tenured peers.
Become “the guy who understands what the accountants need from the database” or the “call center ops dashboard expert.”
I continue to find myself as “the guy who understands what everyone needs from the work tracking system and how to make it happen” guy. But I don’t exactly want to get that pigeonholed. It’s really just something that seems to be part of a common theme of how can we improve our process? I guess the next step is asking – how can I help improve your process?
This is puzzling to me. Why does it matter if clients of your conceptual offering are members of the IT department or not? The IT department has a budget, too. And those are things that affect an IT operating budget in a pretty straightforward way (manual build labor savings and manual testing labor savings). And, with the “better” examples you’re citing, you’re saying that “guy who understands what accountants want from the database” won’t result in arguments with accountants and that “call center ops dashboard expert” will get you noticed by someone that “matters”? Both of these just make me… Read more »
Maybe some of this is too colored by my own experiences or cynicism or whatever, but let’s say you work in IT and have a boss. He has all sorts of “measurements” and “best practices” and “architectural templates”. So either: A) He actually knows what he’s doing and can demonstrate how his metrics translate to tangible good for the company. B) He just parrots a bunch of received wisdom from improper contexts. He operates in a low-accountability environment and spends a lot of time ordering his underlings to scramble around doing things he knows how to measure but don’t actually… Read more »
Thanks for the clarification — that helps me understand. And, admittedly, I’m drifting further and further from the days when I had a lot of detailed interaction with entry level developers and people new to the field in corporate contexts. (Usually when I consult, that’s not really why I’m there.) So there may well be shops where the things I suggested would just lead to a lot of sharpshooting and pointless arguments. Lacking specifics, perhaps I’d be better off with a heuristic than with those concrete examples. My take would basically just be to keep seeking expertise that gave you… Read more »
Here’s a hang up for you though – credibility. How do you establish credibility? Certs? Degrees? Experience? Books? Word of mouth? @Philippe is right, when time becomes a scarce commodity – how do you spend it? Where do we get the most “bang for our buck”? Eric, you’ve got a hell of a rap sheet to establish credibility…especially with the buyers. And all hard-won I’m sure. For those start for time, how about some “life-hacks”? Maybe start my own company, declare myself the CEO and add that to my list of titles. Then self-publish a book or two. And get… Read more »
The main path to establishing credibility, in my opinion, is just to pick something that you have a good working knowledge of (and isn’t overcrowded, like block-chain or whatever is currently at the peak of Gartner’s hype cycle) and stick to it. Sounds generic, but that’s really what it the key is. Say it’s that you’re really good with spatial search (I’m running thin on examples) and you help travel agencies specialize in finding good tours for people traveling to destinations. Start a website talking about that, and just supply a lot of content on a regular basis. Talk about… Read more »
That’s a great way to put it – “an expert compared to the people you’re helping”. In a lot of cases that’s – “how do I do something moderately advanced with my browser?” Or “what’s this button do?” Should be pretty easy, but I guess the sweet spot is finding that something that will be worth my time that someone will pay for. Then marketing that. “Hey, I can solve a whole bunch of your IT problems…how can I help you?” Well…that doesn’t scream specialist. Of course that was more sarcasm than abything. I guess it’s tough for a ENTJ… Read more »
I would definitely advice every developer to work in consulting for some time. I moved to consulting after working 5 years as an engineer and it was a whole new world. There was so much to learn and grow and I loved the fact that you are not treated as commodity. You get a chance to talk and work with people at CTO & VP level. But I was exhausted working in consulting after 3 years and moved back to engineering position in silicon valley. You definitely grow and learn a lot to a certain point but your growth will… Read more »