Developer, You Played Yourself
Podcast: Play in new window | Download (50.5MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
While software development requires a fair bit of thinking, sometimes we as developers are completely blind when it comes to the realms of office politics and personal power. Because of this, many developers are relegated to unfulfilling careers that pay less than they deserve, with much less control over their personal lives than they might otherwise have. It’s pretty common in the United States for senior developers to make a six figure salary, yet many of them are treated in a way that doesn’t match the “esteem” that their paycheck might otherwise command.
In addition, many developers will insist that they have no interest in office politics, yet will be surprised when they find that office politics has an interest in them. As developers, we are required to work well with other people, and that often includes doing things to protect ourselves, our mental health, and our own turf.
It’s ugly. We all have ideas about how things should work. And they absolutely should, dang it. However, to some degree, the stuff we outlined in this episode are true in every organization. You may be lucky and working somewhere where none of these seem to apply. However, you forget this at your peril – human group interactions will always have some amount of this stuff. Even if it currently isn’t present, it can easily regress. Your ability to achieve the kind of life and career that you want is dependent on your ability to understand the political currents in which you swim. If you act with understanding, you can create a better life, but ignore them and you will be forever frustrated.
Episode Breakdown
10:00 Acting/thinking like a peon while expecting high pay.
Senior developers arguing with non-technical management about how to structure an application. Just no. You are a highly paid professional and you don’t put your decisions up for review by someone who doesn’t understand them unless they directly impact the result. It’s not how you argue; it’s that you set things up where your informed decision can be overridden.
Arguing as if abstractions matter more than the business case that you are trying to solve. The business folks don’t care about agile, event sourcing, proper object models, TDD, DDD, or functional programming. They care about results that impact the business. Weaving this stuff into conversations makes it easy to come across as a know it all and can make the other party feel inferior. It’s a bad idea.
Ignoring perceptions is a dangerous game. You may be right, but being right in the wrong way in front of the wrong person is still wrong. Maintaining perceptions is almost as important as being right.
14:40 Giving away your advantages and being surprised when others don’t do the same thing on your behalf.
Smart developers develop practices and tools that make them more effective, then promptly share them with the brown-noser down the hall. Sharing is great, but make sure that management is made aware that it is happening. You have to realize that some less skilled developers are playing politics and will take advantage of you.
Many developers are unwilling to own up to their own successes. We’re often taught to be humble. While that’s good in interpersonal interactions, you don’t want to be the developer who is underpaid. Do not keep your manager in the dark about the value you provide; that’s a good way to be laid off next time.
Humility is good for interpersonal interactions and even valuable at work, but don’t mistake lack of advertising for it. This doesn’t mean bragging, but you do need to use your previous success as proof that you can continue to provide success. Humble-bragging is worse than bragging, as it is bragging without the guts to just do it and is seen as such.
18:50 Letting your value be what other people choose to pay you, rather than setting your pay higher.
It’s easy and safe to never ask for a pay raise, but it also establishes low status. Watch out for behaviors (or lack of behaviors) that indicate low status and stop doing them. Always be moving towards raising your status in slow, continual manner. Your pay is one indicator of that. Your price is capped at what the market will bear for the value you provide.
Being shouted down as the only technical person in the room while the non-technicals promise the impossible. If this happens, you aren’t properly expressing your value. If shouted down, explain the problem and what will happen. If they decide differently, make sure they eat the results.
Remember that your tolerance for behavior is training people how to treat you. If you allow people to regularly treat you like garbage, it’s your fault when they continue. If you want to change the big behaviors, you have to start by fixing the small behaviors that make it look ok.
23:30 Setting things up where there is a winner and a loser, rather than two winners.
Direct conflict is almost always a bad idea. If there is a winner and a loser, you have some chance of being the loser. Instead, figure out how to make the other party a winner while doing what you want done. You should be working to create alliances at work, not because you are manipulative, but because they are necessary for work to be healthy and happy over the long term.
Compromise from a position of strength gives you the leverage to take care of yourself and others. You can be a lot more magnanimous when you can afford to be more magnanimous. When you can’t, you can’t. Remember, if you can do something, you can choose not to do it. But if you can’t do it, you can’t choose to.
Learn to find a way to achieve the goals of others while making yours happen – those people will help protect your idea. There will be competing priorities anywhere you go. If you can achieve the priorities of others while achieving yours, the number of people wishing you success grows. It’s completely fine and expected to have your own goals, but if you pursue them against others, you’re going to have problems.
31:40 Believing that your employee handbook contains the actual rules.
Just compare your employee handbook to what actually happens. If you see someone who consistently is able to bend certain rules – there is a reason for it. It’s more dangerous for you to mention this kind of rule breaking than it is for them to break it.
It is great to know the rules – just don’t use them for prediction. This doesn’t mean that you go around breaking rules. It means you don’t make plans expecting others to follow them. Sometimes you can bend the rules too, especially in extraordinary circumstances.
Even if you play by the rules and are a decent person, that doesn’t mean everyone is. Even the golden rule is broken by some percentage of the population on a regular basis.
35:05 Believing that ideals overcome incentives.
“Should” doesn’t often overcome “is paid for”. Let’s say that you want to go to a microservice architecture – don’t explain it as cleaning up the code, explain it as enabling something that makes money. Be able to back your technical opinions with a business reason or don’t offer them.
Don’t expect people to understand or do things when they are “paid” not to. Similarly, if an established developer has been somewhere for years and has continued to be paid to do things in an old way, you may not have much luck showing them a new way unless it helps them. If a dev hates SQL and has gotten by without it so far, you’re probably not going to have much luck there either.
To understand how things ended up in a tangle, you need to untangle incentives, not results. For instance, if the codebase is a mess because developers are incentivized to get things done quickly, no amount of protest will clean up the code unless the developers are incentivized differently. This is also true of disincentives. If slower, more methodical developers are let go, then you won’t have the other kind and they are unlikely to change.
39:30 Believing that the most qualified are always the most likely to be promoted.
Are you sure of your understanding of what constitutes “Qualified”? The guy that writes the best code in the least amount of time is not going to be promoted out of that position. Whereas the mediocre developer who demonstrates leadership skills will be.
The person that gets promoted is the one whose promotion offers the best incentives to those higher up. What gets you to one level often will not get you to the next. In fact, doing well at just your job requirements will often trap you there.
You need to realize that technical skills are a baseline for a good development job. Technical skills absolutely must be cultivated, but they are the equivalent of basic hygiene. Thinking you’ll get promoted based solely on technical skills is like expecting to get a date because you brush your teeth really well.
43:40 Believing that other people are motivated in the same way that you are.
A naive understanding of other people will make you think that what motivates you will motivate them. We’ve discussed this before. Even among the best of friends, motivations vary. If you deal with other people as if they have the same motivations as you, it’s easy to come off as a bit clueless at best.
People with motivations different to yours can surprise you in nasty ways, especially if you thought you understood what was going on. For instance, motivating Will with a flashy car won’t get you anywhere, whereas a trip somewhere interesting might. When someone isn’t motivated by money, and you offer them a pay raise for something critical, they may well disappoint you.
You need to consider how other people are motivated when deciding how to approach them. This usually means observing someone for a bit. This is the origin of asking someone “where do you see yourself in five years” as well.
46:05 Believing that the chain of command is the most important or even primary way that things can happen.
The chain of command is how things are supposed to work, but almost everyone has their own informal way of finding out what’s going on. Informal communication networks carry more data than formal ones. Look for who goes to lunch together and who stops to chat.
If you don’t do a good job cultivating your own personal sources of information, you will be supplanted by someone who does. If you don’t have good sources of information, it’s easy to ask for a raise when the boss is in a bad mood. Having more information also makes it easier to figure out how people are motivated.
The “chain of command” is an unnatural structure and doesn’t reflect how people generally work together. A chain of command is only as strong as its enforcement mechanism.
IoTease: Article
Cyborg Artist
Born in Belfast, artist Neil Harbisson suffers from achromatopsia. This means that he only sees the world in black and white. So in 2004 he became the first officially recognized cyborg when he had an antenna called an “eyeborg” attached to his head. Later in 2013 he had it surgically implanted. The eyeborg contains a sensor that senses color and converts it to sound that he hears through conduction via the bones in his skull. He taught himself to recognize and identify different colors by the sound they make. The antenna also has wifi and bluetooth capabilities. So someone can send him an image directly to his head.
Tricks of the Trade
Fairy tales are for children. Reality is for adults. You deal with things as they are, or you’ll have the same amount of control over your life that a child has.
Editor’s Notes:
We’re getting better at this remote recording. Please forgive the occasional click in this episode.