Let's Talk About Pay

sjconolly — Mon, 03 Jul 2023 05:00:12 +0000

Your pay, specifically. I see a lot of younger devs going into the industry who don't quite understand why companies are so cryptic about what they pay, and why.

I'll start by admitting that I am a boomer, and like many of my generation I'm a lot more focused on dealing with what is than what should be. I too, believe the world would be a better place if we were all paid what we are really worth, but there are a lot of factors working against that.

Lesson #1 - you don't get paid what you're worth, you get paid what you negotiate. Corollary - if you're not negotiating, then you are absolutely not getting paid as much as you could be.

The best tactic I ever came up with was a complete accident. After the company did another round of raises less than 1%, I naively said to my boss "oh well, at least it won't be that hard to match if I ever have to leave". Very fortunately for me, my boss realized that I didn't mean it as a threat at all, I was just trying to find a positive angle. He then went back and got me about a 15% raise by pushing me to the top of the range for my slot, followed by a promotion and further raise the next year. There's no harm in gently discussing what you think you're worth, and why.

Lesson #2, is that you are generally paid according to the role you fill - not how well you fill it or how much more you contribute. If your slot is for a Developer I, you should expect to be limited to that salary range until you get promoted. That range is not set according to anyone's worth, it is solely set to the market conditions. The company (usually HR) will set a salary range to be competitive enough versus other companies. They don't have to offer the best pay, it just needs to be good enough that most candidates will probably not expect much better somewhere else.

All right, so a few years go by, and you're not a green fresh grad anymore. Your manager loves your work and is endlessly grateful for your contributions and leadership, but guess what? You're still in the same role, and so you're still in the same pay range, and that's all the company is willing to pay for. Because in their math, that's the level you will be competing at if you try to look elsewhere. It's a kind of brinkmanship, they will try to carefully offer just enough to keep you from looking elsewhere, and they know most people are really reluctant to leave until the job becomes intolerable.

So why can't your manager work through that? Most companies with more than a few hundred employees will have polices to restrict the managers freedom regarding salary. Generally companies want to treat rank and file employees as commodities, where the pay is determined solely by the market conditions for that specific role. That's part of their strategy for getting the most staff at the lowest cost. Your manager likely has no power to raise your pay above your range, and has a limited number of slots in the next pay range that you could be promoted to. Most of the teams I've worked with had slots for maybe a half dozen entry level devs, two mid-senior devs and then the manager, who might be at the same pay range as the mid-senior devs.

The strategy for dealing with this is actually simple - be willing to move to other teams or companies as often as you need to. Really, the only reason to stay with a team in the same role indefinitely, is because you are totally 100% happy with team, the company, your pay and benefits, working conditions, etc. After you've been in a position for a year or two, and you're not happy with anything on that list, then you should be keeping your eyes open for a new position. Life is far too short to dedicate yourself to a position that doesn't satisfy you.

Which brings me to lesson #3. Many of you might think that all sounds fine, but you can't afford to take any risks that might jeopardize your pay or benefits, probably because you're the one that has to support your family. This way of thinking is nothing less than a trap that we set for ourselves with self doubt. If you had a chance to grow your knowledge and skills (like with a better team) you would be better positioned to compete for the best jobs (at a better company) and would be a whole lot happier about it (improving your own well being and your family's at the same time). If you think you can't afford to take a chance, you almost certainly can't afford not to. OK, this my highly opinionated view, but I see countless people who feel trapped basically because of the imposter syndrome. They can't conceive of how much they can really accomplish if they are willing to just go for it.

The way to be competitive, is to work hard on being the best dev you can be, and there will always be companies willing to compete for the devs that have locked into that. These devs are the ones who are the most effective at their craft, and every major project must have a least a few of them to be successful. You're not competing as much on the role you can fill, but instead on who you are. You don't have to grow a horn to be a unicorn.

And for those who stuck with me to the end here, a final bonus: what is the most valuable skill to master (at least in my opinion). Having had a long and diverse career, I found that the one skill that has carried me through all of it is being able to analyze and debug systems... that I don't fully understand. Basically, if you learn how to figure out a system to the point that you can find the problem and the fix, there is always someone who will pay well for that.

Why do Software Projects Fail?

sjconolly — Sun, 11 Jun 2023 01:40:59 +0000

(My first post here!)

If you've been in this industry for any length of time, you've come across failed projects, or perhaps have been stuck on a few yourself. It drives an entire industry of project management tools to keep projects on course, and armies of highly paid consultants to protects businesses from costly mistakes, and in my opinion, a whole lot of snake oil and silver bullets to go along with them.

I've been involved with many, many projects over my career, and I've been lucky to spend time working with some great engineers at a number of companies, who have shared their own stories about what has worked and what has failed. And both my first hand experience and the second hand stories have all led me to the same conclusion.

Software projects rarely fail for engineering reasons, that is anything that is under control of the engineers themselves. The biggest cause of failure is simple communication - the client simply does not understand what they need, or that need isn't being described accurately in the contract and requirements. Usually the dev side will churn along and deliver what was requested, at least requested in writing, but it will not actually deliver on what the client wanted.

The number two cause I've seen, sadly, is plain deception. A company agrees to develop something at an unrealistic price, hoping that they can find a way to renegotiate along the way to cover the actual costs. A variation on this is when a company is being paid to develop the requirements, and then keeps charging to refine the requirements until the project becomes outdated and eventually killed. Even though the development process never started, I still consider it a failure since the client paid, sometimes in the millions, for something they never received.

Opinions and stories welcome!

DEV Community: sjconolly

Let's Talk About Pay

Why do Software Projects Fail?