You Should Change the Reason People Pay You
You Should Change the Reason People Pay You
The quintessential argument for specializing instead of generalizing makes all the difference in development.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Quick — what's the reason people pay you? Don't ponder. Just freeze the first thing that comes into your mind.
It's probably something like this, especially if you're a salaried programmer.
I have a valuable skill that's in high demand: programming.
On a surface level, I can't really argue with that. Recruiters pester you constantly, and companies regale you with the superficial perks that can be yours if you just jump ship and come work for them.
But your skill and the demand for it aren't the whole story. In fact, I'd argue, they're not even precisely the right story.
Why Do People Give Programmers Money?
Let's tweak your prognosis slightly, without changing the economics around it. You think of yourself as a knowledge worker that has a skill in high demand. But your employer views you as a commodity in short supply.
What's the difference? Isn't this semantic quibbling?
Not at all. Inadequate supply can create excessive demand (or vice versa). But they are not the same thing. To understand what I mean, think of runs on grocery stores for canned goods before major storms come through. Cans of baked beans are budget, commodity goods that nobody would generally call "valuable."
But that all changes when a hurricane appears on the horizon and people hoard canned goods for the aftermath. Gougers can charge way more for canned baked beans because it's a commodity in short supply.
As a salaried programmer, you're a can of baked beans. Don't confuse short supply with intrinsic value. The world is starving for efficiency, and it anticipates even more starving later. Employing you is a hedge.
Generalist Programming is Commoditized Efficiency
Let me break this down a little more. Think of the company that hired you most recently.
Maybe they deployed you immediately on some ASP MVC application using Angular on the front end. So high up on the list of "required skills" in the job description sat C#, MVC, Angular, and probably a handful of other things related to your source control, CI, and various libraries and dependencies.
But then, maybe you saw a few odds and ends in the "Pluses" or "Nice to Haves" section. Why does this shop want someone that knows Go and/or VB6? That's odd.
Ah! But then it makes sense. While interviewing, you realize they have a legacy VB6 app that interacts with the flagship codebase. And, on top of that, they're looking to migrate to Go in the future. So, of course, they list these things as pluses — it'll be easier to deploy you to work on those after your initial assignment.
In hiring you, the company wants a generalized programming resource. They want someone that can handle today's needs and also any that come up in the future, whatever they might be. You're the techie equivalent of a handyman, as opposed to a plumber or electrician.
And thus the hedge. You're not really great at anything, but you're adequate at programming in all forms. As long as you hang around, handy-manning whatever comes up, they have a closet full of baked beans to sustain their efficiency needs.
Commoditized Labor Is a Race to The Bottom
Being a can of baked beans is a pretty decent deal in a world where a hurricane is imminent. And that's our world now. There's a huge programming labor shortage, so you can count on companies to (over) pay for your services. In fact, you can probably count on this as a good deal for a while.
But it has a curious effect on you when you try to differentiate yourself meaningfully. It makes the price of your labor sticky and more or less divorced from considerations like quality.
Think of it this way. In a post-hurricane world where food is scarce, danger is real, and baked beans are going for $20 per can, are you going to pay 10 times as much for a meal of steak, the way you might in a normal economy? Would you pay even $25 for the steak? Nah, probably not. If meals are scarce and going for $20 a pop, you'll probably pay the $20 to conserve your resources until better times.
This is how employers approach programming labor. They have to pay a lot for it. But it's a rare employer that's going to pay substantially more for your services than to simply shrug, say "Thanks anyway" and move on to the next resume in the stack.
When you're a commodity, you're always in a pricing race to the bottom. It just so happens that commodity programmers have a high bottom. For now.
First, You Need to Stop Being a Commodity
All of this means that you have a pretty serious ceiling on your earnings as a programmer. It's a nice, high ceiling, but it's a real one. Don't let the occasional $200+K programming gig in San Francisco or on Wall Street fool you. For most, that cap is going to be something like $130K unless you go into management.
You might be able to goose this a touch by hanging out your shingle as a freelance app dev seller. But not by much, once you factor in the overhead cost of running your own business and not being 100% billable.
To break this cycle, stop being a commodity.
What's the conceptually simplest way to do this? Stop being a general app dev resource in exchange for money.
Instead, pick a specific type of engagement and delivering only that. Maybe it's legacy rescues. Or maybe you build Angular front ends for companies moving to more client-heavy web apps. You'll have to figure specifics out for yourself.
But you can de-commoditize by making sure of two things:
- You deliver a specific, specialized thing at which you become progressively more expert with time.
- Your deliveries have limited scope and duration. You're not just hanging around, doing whatever needs doing.
Then You Need to Build Authority in a Capacity Where You Solve Problems
An interesting thing happens when you specialize this way. If you do a bunch of legacy rescues or Angular overlays, you become a legacy rescue or Angular overlay expert.
Considerations like resumes and interviews just naturally melt away. An intermediate step might be that you're one of several candidates answering an RFP or something. But even that fades when you're focused enough.
Buyers and companies you interact with start to regard your expertise as manifest. You can aid this along with conference talks, books, or other vehicles for establishing authority. But even just a sufficient past work portfolio does the trick.
Strive Toward Receiving Money for Expertise and Expert Advice
And when you find yourself in this position, something naturally starts to happen. People will start asking your opinion on things, whether or not you subsequently deliver anything. "Would a legacy rescue even help here?" "Should we do an Angular overlay?"
Many recovering resources fumble away this opportunity, viewing the answers to questions like these as pre-sales giveaways. DON'T DO THAT!
When people start asking you for advice, package that advice into some kind of offering, like an assessment or a roadmap. As soon as it's viable, move from accepting money for labor to accepting money for advice.
Finally, Delegate or Oversee Execution
As time goes on, you'll find that you can charge way more money for advice than you can for labor. I've touched extensively on consulting residing in the realm of diagnosis and prescription, rather than application of therapy. And I've also touched on why I think all developers should strive to become consultants.
You'll find yourself in a transition period for a time as you develop your consultative chops. Companies will ask for a legacy rescue assessment, and then they'll ask you to perform the rescue. As this happens, you're building out an assessment playbook, probably some intellectual property of your own, and a general methodology.
Once established, you get to a situation where you don't have to do the execution yourself. You can, if you want. But you can also delegate it. This is perhaps the most important step from being a resource to an actual player in the software game. It's your expertise, your playbook, and your results that buyers want. They'll do it on your terms, and trust you to decide what to do yourself and what to delegate.
But none of that happens as long as they're paying you for generalist labor. So stop depending on hurricanes to sell yourself as a can of beans. And don't even sell yourself as a steak. Sell yourself as the expert that can help them prepare for hurricanes.
Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.