Does your IT salary depend on what makes you different?

"Rational people" think at the margin...

It’s Monday, and that means I take another crack at an economic principle and apply it to software development and IT. (Here is a link to the series so far.)

This week we are on principle #3 which goes something like this:

Rational people think at the margin.

I am going to put aside questions about whether (or which) people are “rational”, or whether I would be qualified to make the assessment in the first place.

Instead, I want to focus on the “margin”. (Perhaps that makes me “rational”, after all.)

In this context, the “margin” relates to an economics principle called “Marginal Utility“.

A summary of the concept (for our purposes, anyway) is that people will value two otherwise equivalent items against each other based on their “marginal” (or incremental) differences, positive or negative.

So we might pay more for one car based on its gas mileage or on its performance characteristics, all other attributes being pretty much the same.

Fundamentally, the market of buyers and sellers converges on a certain price at which a commodity might be bought or sold.

As long as a surplus of buyers or a shortage of supply exists, prices may rise… and the converse also holds.

Designing for marginal utility

Now, if a company wants to sell its products at a premium, you may have heard that it needs to “differentiate” them in the market.

More specifically, the company needs to name, find or design a marginal utility for its offers… an incremental change that drives a disproportionate increase in assessments of value (price).

Don't quit your day job!

My business teacher, Toby, used an analogy like this (the following numbers are illustrative only, and may not be accurate):

  • A “good” college basketball player, scoring 26 points per game, has no chance of becoming a professional…
  • A “great” player, routinely scoring 30 points per game, might get drafted at a league minimum salary…

While…

  • The “elite” player who always scores 34+ points per game might get a starting salary ten times higher (not to mention endorsement deals and other additions to income)

Looking at it that way, you could say that the difference between getting into the pros and not is 2 baskets per game.

You could also say that the elite player gets 90% of their income from the extra 2 baskets they make every game.

Bringing the topic back to IT

Since I thought it would be good to set up what marginal utility is and offer an illustration, it seems to me that we can spend a couple of weeks on this subject. We can speak about designing marginal utility at the individual, team and organizational levels.

So while we have the notion of salaries fresh in our minds, let’s start with you and me, shall we?

First, let me make my intentions really clear: I accept that people say money isn’t everything. People don’t have to slave and toil to get paid more. There is nothing morally ‘right’ or ‘wrong’ about wanting higher pay or not.

Remember that the topic is marginal utility in the domains of software and IT. So I am just speaking of the topic about how much we get paid. That’s all – I have no judgments and am not making any recommendations – “I’m just sayin’.”

I have nothing particularly witty to write this time - this is a piggy bank on a pile of money.

In the basketball analogy, good players don’t become professionals. There is nothing wrong with them – they’re good… just not valued highly enough to get in at that level of competition.

In my career, most of the IT people I’ve met are good.

They get paid what the market bears for their roles, which our industry declares clearly and consistently in job descriptions from one company to the next.

A Java developer is a Java developer, and they make a certain amount of money. They make a little more as a consultant, generally speaking.

A “senior” Java developer wants to get paid more, but the standard for assessing what “senior” means is not well established.

And don’t get me started on what an “architect” really is in all its various derivations… except they also expect to get paid more, and have higher expectations to live up to.

The point is: as long as what defines your capabilities and accomplishments is the same as everyone else, the market sets your rate pretty clearly.

In this situation, your income fluctuates with the market, and you are a commodity, in a sense. A business may see you as replaceable, you may struggle to find your next role and you may feel trapped in roles, feeling underpaid and undervalued.

On the other hand, when you find those strengths that you bring to bear – those things that makes you incrementally more valuable than someone else in your role – that could be marginal utility (your “2 baskets more“) for which you compel other to pay a premium.

Just be careful in thinking that what you value about yourself is what they value, and that you deliver enough that they will feel your premium is worth it.

Advertisements

Unintentional “lies” in the software development field?

Beware the Chicken-a-saurus!

Marketing folks have learned a few things from software developers.

It is funny to me that developers often speak of marketing professionals as if they mainly lie to people about what they want to hear (or as if that were a moral thing).

I say that because it sometimes happens in our industry as well… maybe more often than we want to admit.

80% complete

I remember when I was just getting started in software… senior developers would report their tasks being 80% done… and remaining 80% done for weeks afterwards.

On better projects, they would report 80% complete on their first status report, and then 85%, 90%, etc.

And some of them couldn’t tell me what the “method of successive approximations” was. Go figure.

“Ready to ship” in 3 months

Or how about another example – that the software will be ready to ship in “N” months? In a recent MarketingProfs short, “How to Sift Through Unintentional Lies”, it cautions marketers to brace themselves for “one lie after another”.

It is worth reading, not so much to raise your hackles, but to learn about the perception we create in customers in whom we want to build an assessment of value. Though the article speaks about other domains than software, here is a fragment related to us, from their perspective:

No development team wants to miss a deadline—but it will happen. “There’s one project I’ve been watching that has literally been three months away from shipping for 18 months now,” notes Anthony. You’ll get more reliable estimates if you eschew a single, long development cycle for rapid cycles that produce a “minimal viable product” for testing and further augmentation.

[Bold emphasis mine. Again, please read the article at the source reference I included in the preceding lines.]

So there you have it… marketers asking for agile delivery of value. That’s pretty cool and a good place for us to work together on rebuilding trust.

Notice the article is careful to say the development team is not being malicious or intentionally deceitful.

I cannot remember a case where we have been, either. Most developers I know love to write software. We love to create and we love to solve puzzles… but let me highlight a third example before we close for the day.

Trusting each other

Now, there are explicit promises and implicit promises. In fact, it is the implicit promises that can do the most damage. You can try to disavow them easily or you may not even realize others think you made them in the first place.

In this case, DON'T read the manuals!

Have you ever made a promise to a teammate that you intended to keep, but failed in the end to keep? I know I have.

Did you ever “break the build” or overwrite someone else’s changes because of a merge conflict? I have done that, too.

Have you willingly taken on some task for a long time, and then just decided not to do it because it wasn’t really yours to do? Did anyone depend on it getting done, and did they know you stopped doing it?

Did you know you’d made a promise, or acknowledge the breakdown you produced? Not always, for me.

Do you think that failing to notice that you made a promise in the first place makes it any easier on the person you let down?

These are situations we create with our own teammates… and yet we sometimes try to diminish the importance of the cost we produce for others in failing to hold the promises we make.

Keeping promises requires professional attention

Many people write about agile methods being based on a notion of trust (including me). Quick releases, adaptive requirements, continuous integration, better testing and quick communication can go a long way to help us make and keep promises.

There are many levels in a project in which we make promises. They all count, especially in the eyes of those who accept our promises.

Keep the ones to your customers, but also keep the ones to your teammates.

Think about this – You may be committed to the top thing or two on your list, and everything else gets shifted around and de-prioritized. Though it makes you feel better to tell others you are over-committed, you may really be over-promising and failing to commit to the promises you make.

What hurts others also hurts your identity with them.