We are stoked to have Cristian Medina (tryexceptpass.org) deliver our first soft skills article. He will go into depth on the topic of promotions and how to better position yourself as a developer. He will discuss performance reviews, the role your manager can play, networking and much more. Enjoy and keep challening yourself! Enter Cris ...
I'm going on year 16 of my professional engineering career. Most of it spent in large and mid-size corporations. In this time, I was exposed to a number of interesting situations and processes related to performance reviews and promotions. And while I was at Pycon 2018, the topic came up in some hallway conversations. Specifically, what does one needs to do to get promoted?
Anthony Shaw actually covered the basics in his Can we talk about tech salaries article about negotiating better pay. But the hallway discussion left me thinking that there's a few more things I can add to the list. Perhaps some that might help explain the process better for folks that have never been through it. Especially how it works in larger corporations.
When the guys from Pybites suggested collaborating on a new post on soft-skills, I thought this would be a good topic to cover. So here we are.
First thing is first: Be good at what you do (i.e. your primary job), otherwise the conversation is over before it even started. Were it gets tricky though, is how you measure "good". Each company has multiple ways of doing that, usually different between business units.
Second thing: Don't just stop at your job responsibilities, make it your mission to learn about how to improve your environment. I know this is broad, but that's the point. If it means learning a new programming language, a new tool, or new methodologies, it's on you to stay up to date with your chosen profession and how you can apply recent developments to your environment. Not only is it good for you, but keeping your department and organization up-to-date can even make it resilient to future complications.
Some businesses have a core set of values against which they'll evaluate what you're delivering. These tend to be "esoteric" things like "innovation that matters", usually very abstract and hard to measure (this is likely on purpose). To use this phrase as an example, who is the innovation supposed to matter to? your clients? your coworkers? the "business"?
Other organizations will rate you on specific measurable criteria. This brings the problem of understanding which criteria matters to your job role. For example, while it might mean a lot to you personally that you've made 5000 commits (more than anyone else) to the most important codebase the company owns, maybe the company wants to optimize dollars spent building code. In this case you just cost the company more money than everyone else, and therefore had the worst job performance.
Other companies will instead have a list of specific criteria for each of the "steps" in your career ladder. Keep in mind though that this ladder is for the career that your job category falls into, not necessarily the one that YOU want to climb. The criteria could also be abstract concepts, like step 1 would be "implements the vision", while step 2 is "interprets the vision", and step 3 is "has vision". And yes, there are all kinds of jokes you can make about what you need to do to have visions, but this is a real thing I've seen in several places.
It's very important that you first understand how to provide value inside your company. Which is not to say that it works the same inside your organization, or even your department. Usually there's other "flavoring" added to each of those items depending on where you work, who you work for, who they report to, and even who they report to.
Make sure you find mentors or other folks in the organization that have gone through several steps in the ladder WHILE WORKING AT YOUR COMPANY. They can help you understand what matters. Your manager can help point you to these folks, and if not, a peer manager should have some input as well.
Ok, now that you you've determined how value is measured, it's important to make your performance reviews, especially the written ones, all about how you deliver on that value. Sometimes you won't be able to put things in the same terms, but that's where you talk to your manager and ask for advice. Don't forget to mention any research or studies you completed, even if their conclusions were not what you expected.
Performance reviews are not a place to hold back, this is where you get to be a rockstar. Being humble will not help you here. You don't need to write an essay, bullet lists are usually better. You could categorize the bullets by your organization's criteria, if it helps.
Managing people is NOT easy. In general, management chains tend to get a bad rep for bad decisions, but they hardly ever talk about the good ones, though I suppose this is how it should be. I haven't been a manager myself, but I have been in team-lead or "coaching" roles in different organizations, and even outside of business environments. You learn real quick that people aren't easy. Keeping track of who has what problem, when, why, who can fix it, where they can fix it and with what kind of help is NOT a simple thing.
YOUR job is not only to be good at what you do, but to make your managers job easy. If your manager gets a ping from someone external to your department about something dumb you did, that's yet one more thing that they have to deal with in their day. If they show up at some higher-up meeting and are asked something that you did not prep them for, they might look stupid without a good answer. That's one more thing they have to worry about next time they present your project.
YOUR job is not only to be good at what you do, but to make your managers job easy. If you can't point to things you do to make your manager's job easier, then moving up the chain gets a little harder.
Promotions DO NOT imply more money. Sometimes they do, sometimes they don't. When you're looking for a promotion, make sure to understand what you're getting yourself into. Sometimes there's a promise of money, but it winds up being a 1% raise for 50% more responsibility. If you don't ask, you'll find out the hard way. Don't make your life more complicated than it needs to be.
Back to an earlier point about the steps in the career ladder, it's important to have an understanding of salary ranges for each of those steps. Usually there's a very strict range for each step, and where you are on that range is very important. If you're on the lower end, then your higher priority is to keep doing what your doing and look for a raise. If you're on the higher end, there's no point in having a conversation about a raise, because you need to be promoted first before you can get one. Your manager can usually tell you where you stand, some companies even require them to do so.
On top of all this, there's "tribal knowledge". The grape vine is a real thing and it always has information about what certain management chains may or may not want, who might be leaving their position soon, who might be wanting to come in, who might be on the outs with their manager. This is NOT about gossip or hearsay, instead it's about taking the pulse for your organization. You need to understanding it such that you can gain insight into the opportunities that may or may not interest you.
Sometimes it's not until you have these conversations with your coworkers that you realize that things aren't heading in the direction you need them to go. This can help you determine whether it's better to spend time vying for a promotion, or to start looking for another job.
Networking also helps you find other jobs within the same company that may have the career ladders you'd prefer to climb. Or different environments where you think you can better excel. They might even be in departments with peer managers, which makes life easier because you already understand the organization.
Large corporations don't tend to go around thinking: "Oh! This guy did a great job! Promote him!" It doesn't matter how much they want you to think they do, that's not how it works. It's all a numbers game.
For example, the business may have a percentage of the budget set aside for promotions, which they usually equate to a count of how many people they can promote for the year. Then that number gets distributed amongst all the business units, which then divide it by the different steps in the ladders (i.e. we can do 50 step 0-to-1 promotions, 25 1-to-2, 10 2-to-3, etc.) They then trickle it down to the organizations and departments, normally stopping at the 2nd-line manager level. The distribution method varies greatly between companies, some base it on how the business units did against their goals for the year, some base it on % revenue generated by the units, etc.
At this point, there's usually a meeting where your 2nd-line gathers his troops (your manager and his peers), to decide who gets what promotion to which step. Now comes the tricky part. Each manager brings a list of his candidates, and they all discuss each candidate and their accomplishments.
Some folks don't really understand the significance of this point: Every peer-manager in your organization will likely have a say on whether you get a promotion or not. On top of that, as we discussed earlier, a promotion to each step of the ladder has its own set of rules, which also involves approvals. The higher the step in the ladder the higher up the management chain you go for approvals. That's why it's sometimes easy to get the very first promotion which only takes your direct manager and his manager approve.
What does this mean to you? It's not enough to do a good job for YOUR manager, you should also do things to help your coworkers in other departments. If the peer-managers haven't even heard of you, how can they be ok with giving up their guy's promotion to you! Back to making your manager's job easy, this is a key aspect of it.
If you help other people, make note of it in your performance reviews. Remember, it's not about bragging, it's about making your manager's job easy. When that peer manager doesn't know who you are, he could say: that's the guy that helped you with the XYZ task you were stuck with last month.
Let's say you were super helpful and your colleagues want to take you out for lunch. They want to thank you for this cool thing you made for them that greatly simplifies their lives. Tell them you'd love to go out for lunch with them, but they should save their money and instead of buying lunch, email your manager AND their manager thanking you for the work. On the flip side, you should do the same for them! When you think someone did a great job at something, email them and copy your managers. It helps everyone.
Helping other organizations or departments doesn't have to be complicated. As a programmer, this might be simpler than you think. Here's a few quick ideas:
Develop tests for fellow programmers. Having another set of eyes that don't know the codebase usually leads to interesting questions.
Help review someone else's code.
If other departments maintain APIs, try writing wrappers for those APIs. This usually provides good insight and will help them with testing.
Run some short training sessions on topics you find interesting or anything new that you've learned. Passing new knowledge onto other coworkers is a great way for you to easily retain the info.
Many times you'll engage with individuals or departments that have to run a lot of metrics. Sometimes, these folks are burdened by company "tools" and their limitations. Try lending a hand in configuring those tools so they make more sense, or help formulate "advanced queries" with actual SQL instead of the limited options given by GUIs.
Since you now know what your company finds important to measure, why not put some internal website together to help visualize it. You can graph defect data, support cases, performance data, test execution, etc.
Monitoring tools are also useful. If you run any kind of infrastructure that's expected to be up-and-running most of the time, it's not hard to make a few simple systems that can alert when they go down, or call REST APIs to check on statuses.
Keep an eye out for scriptable work. Generating reports is a great example, as well as tasks like onboarding recruits or cleaning up resources after other people.
There's always some kind of resource management or inventory system that could help a department track things better, or automate something.
Did you recently fail at trying to implement something with a given approach or technology? Pass on the knowledge in a tech talk.
When I was naive and early in my career, I definitely wish someone sat me down and went over these points. It would've saved me lots of frustration and heartache. I hope you find them useful.
Keep Calm and Code in Python!