Practical .NET

Maximizing Your Paycheck

Obviously, supply and demand controls what price you can charge for your work. C# developers aren't paid more because they're smarter/more educated/technically superior than Visual Basic developers: They're paid more because the gap between the supply of C# developers and the demand for them is greater than the equivalent gap for Visual Basic developers.

But supply and demand doesn't explain everything. Way back in 1979, Michael Porter proposed a model of five forces that explain profitability in many industries (and "being a programmer" counts as an industry, I think). What's interesting is that you can use that model to make strategic decisions that will let you charge more for your work.

Driving Up Price
The first force to consider is substitutes. Instead of buying a car to commute to and from work you can substitute carpooling (use someone else's car), biking or taking public transit. The farther out you look out in time, the more substitutes you have: You can, for example, move closer to work or change jobs so that you don't need a car to commute. The more substitutes there are, the lower your price must be.

And, conversely, the fewer substitutes there are, the more money you can demand. You must present to your employer (or potential employer) a unique combination of training, education, experience and personal traits that no one else has. And, while lots of people might be able to duplicate your training/education, it's harder to duplicate experience and personal traits. Have you got lots of industry knowledge? Are you naturally empathetic? Do you excel at working with data or at making intuitive leaps to the right answer? Make sure that those are part of the package you present to an employer to eliminate substitutes.

The second force is related to substitutes: barriers to entry. If it's hard to break into an industry, then companies can charge more for their products because they don't have to worry about attracting competitors. From your point of view, if it's hard for others to acquire the skills that you have, then you can ask for more money. A good strategy here is picking a technology that gives new developers few opportunities to acquire the skills for.

But don't ignore the value of experience: It's hard for others to acquire skills that only accumulate over time. Hanging around a company (or a specific technology) for a long period of time allows you to learn things that others can't -- at least not in the short term.

Bargaining Power and Rivalry
Two of the other forces relate to the bargaining power of your customers and suppliers.

Customer bargaining power is the one most obviously related to what you get paid: If you have few customers (and no possibility of acquiring other customers), then those customers can bargain down your price. To put it another way: If there's only one person you can work for, that person will tell you what you'll be paid. You should develop a skillset that's attractive to multiple customers.

Supplier bargaining is probably less relevant to what you're paid. The idea here is that, if a company is making a lot of money, then that company's suppliers will try to capture some of that profit by bargaining up the cost of what they sell.

Still, this force isn't completely irrelevant: You want to make sure that your skillset isn't tied to a particular environment or some technology/certification that you have to purchase. In those scenarios, if you can command a high price for your work, those suppliers can expect to charge a high premium for what they supply.

The last force is affected by the other four forces: How competitive is your industry? If there's a lot of competition in an industry, then companies get hit with a double whammy: They may have to lower their prices to stay competitive with the lowest-cost producer while increasing their costs in marketing and research and development to attract customers. In terms of driving up what you can charge for your work, you want to reduce rivalry: Consider jobs that other people don't want.

Conflicting Priorities
Finding a skillset that meets all these criteria well is probably impossible ... but there are always opportunities.

I'll stay away from a .NET example to avoid arguments, but, for example, becoming an expert in the MUMPS programming language meets virtually all these criteria. Certainly, MUMPS offers fewer potential substitutes (LinkedIn shows about 900 members listing MUMPS vs. several million members listing C#). There is a danger that an employers' substitute for MUMPS developers is abandoning MUMPS, but it seems like the reverse is true: More employers are adopting MUMPS than abandoning it.

There also isn't much suppler bargaining power in this field (training courses in MUMPS seem to cost about the same as training in any other development system). A quick search on Monster.com turns up a couple hundred related jobs in the U.S. That's still a lot of potential employers and, compared to the low number of developers available, customer bargaining power seems low.

While the relatively low cost for training means that barriers to entry are low, even a few years of experience would increase those barriers dramatically, especially if you focused on picking up industry knowledge (MUMPS is used most in the healthcare and financial fields).

Putting it altogether, you shouldn't be surprised that the median salary for a MUMPS developer is close $100,000 (C# developers average just under $70,000).

And that's all very interesting ... for MUMPS developers. The real question is what are you doing with your skillset?

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.