On eng ladders, promotions, glue work & success
Many disclaimers belong here, including, but not limited to: This probably applies differently or not at all in organizations without formal ladders and review processes; most and perhaps all of the early-career women I’ve coached on this have been white, and some but not all have been from non-traditional backgrounds; it is OK if you don’t want to climb a ladder; some companies are evil, and some managers are bad, and also the patriarchy; “the business,” at the end of the day, is nameless faceless capitalism; nothing is fair; and finally: this may read as harsh in parts but I’ve found that many people appreciate and benefit from the directness.
A lot of the advice I might share from my own early career, such as “make friends on IRC who will work at cool places in 15 years and refer you” or “participate actively in the comments section of your personal WordPress blog, where you write about jQuery” just doesn’t feel very applicable these days.
There’s one piece of advice I find myself giving over and over, influenced by my more recent years as an engineering manager. This comes up all the time when I’m talking to early-career women pursuing a career and professional growth in software engineering — that is, women who have ambitions to climb the engineering “ladder.”
A gross oversimplification of such a ladder might progress something like this:
- You write code to complete tasks that are valuable to your team. You have relatively few opportunities to make big mistakes, but when you do take advantage of those opportunities, you learn from it. You’re still figuring out exactly when to ask for help.
- You complete tasks in order to help your team complete projects. You’re good at unblocking yourself. You still make mistakes — you will always make mistakes — but some things that used to feel hard or scary are easier. You’re developing a solid understanding of the systems your team works with and depends upon.
- You own and drive small to medium projects and contribute to defining and achieving your team’s goals. You’re good at unblocking others on your team, and others on the team look to you for guidance. You have a growing sense of the architectural world outside your team.
- You own and drive large, complex projects. You guide your team in defining goals that align with the org’s mission and vision, and you contribute to defining your org’s goals. When you’re at your computer, you’re more apt to be reading or writing docs than you are to be writing code. You have a high-level understanding of multiple business-critical systems, and are well-versed in at least one critical system.
- You’re working with other leaders to set a mission and vision for your org that aligns with business needs, and then collaborating with those leaders to guide your org accordingly. Coding is pretty rare, but your technical instincts, experience, and understanding are essential. You have at least a high-level understanding of all critical systems and how they interact, and deep knowledge of several critical systems. You bring experience from other relevant companies.
Three things I’ve learned about this type of ladder: first, that people, process, and political skills (basically the sort of stuff that Tanya Reilly calls glue work) go from useful to valuable to essential as you move up the ladder; second, that these skills do very little to help you climb the first couple of rungs on the ladder; and third, that there are greater than zero engineering managers who know the first two things but don’t know how to communicate them to their reports who are struggling to get promoted.
So, here’s the thing that I tell so many people who are trying to make those first couple of jumps (and maybe this will give managers some language they can use too):
When “the business” is considering whether to move you up the ladder — which will plausibly result in you making increasingly more money for the rest of your career — your manager has one fundamental question they need to answer:
Will I be able to review this person as “meeting expectations” at the next level during the next review season, in a way that is true to the letter and spirit of the ladder?
(Because of course any decision that wasn’t true to the letter and spirit might be characterized as favoritisim or bias.) A manager can’t “jk” about a promotion they end up regretting when they can’t defend it after the fact; often the only way to take it back is with the dreaded performance improvement plan.
Perhaps your manager has pitched the impact of your glue work to get you good performance ratings in the past, allowing them to avoid harder conversations about next-level expectations while keeping you happy. What you might not know is that the impact of that glue work is at best tangential to the question of whether you can meet the business’s expectations of an engineer at the next level.
“But the business should value a wide variety of skills; every engineer shouldn’t have to be the same!” Well, the business does value a wide variety of skills … in a wide variety of job titles, at a wide variety of prices. (Remember, “the business” is, at the end of the day, nameless faceless capitalism, as disclaimed above.) You are being evaluated against an engineering ladder in exchange for your skills being priced on the engineering scale. That ladder wants you to write a lot of code at the lowest rungs.
Charitably, the ladder doesn’t value non-coding skills at lower rungs because those skills take time away from gaining engineering skills and experience that will be necessary to get to the next level. But no one is strongly incentivized to tell you that — your team likely values the non-coding skills you bring, and your manager especially appreciates them, because you’re making their job a lot easier. It might be up to you to figure it out.
Uncharitably, “the business” is getting glue work at a steep discount, like grocery stores getting you to bag your own groceries because they gave you control of the scanner thingy and the ability to interact with one less human (unless you are buying alcohol, but then at least the interaction is brief and explicitly perfunctory). Your skills and your willingness to do the glue tasks instead of the work that will get you promoted … together they mean that “the business” didn’t have to hire someone extra for that particular skillset, and you stayed relatively inexpensive. In addition to being affordable, early-career engineers are relatively easy to get to a sufficiently productive steady state, and relatively easy to replace (in the U.S., at least) if they don’t have a clear trajectory.
Did “the business” set out to be so zero-sum? Probably not. And yet you’ll do best if you assume it is.
If you’re still in your first couple-few years and you aren’t hands-on-keyboard writing and reading and reviewing code and talking about code most of the time you’re working, if you haven’t yet established that trajectory I talked about a minute ago … you are a good and valuable human! Maybe we could be friends!
But the first conversation we’re going to have is how you’re only hurting yourself if you aren’t focused on the ladder if what you want is to climb the ladder*. And if you’re realizing that you enjoy your not-coding time at work more than your coding time, we should talk about that instead. There are a lot more jobs in this industry than I ever imagined when I was getting started, and only a few of them require teaching computers to do things if it turns out that’s not your thing. It’s a lot easier —and feels a lot better—to climb the ladder of success in a job you enjoy.
(A good work friend of mine who knows me quite well once had the guts to suggest that maybe I’d enjoy being a product manager. I was offended and he was right and I was offended more because he was right and I knew it. I wrote him a long note in the wee hours of the morning when I couldn’t sleep because our conversation had upset me so much. I told him how it felt to have a senior, white male engineering leader suggest that maybe I was a better fit for a product role than a role as a fellow eng leader, and how it felt like it went against everything I had worked hard to achieve to even CONSIDER the idea.)
(And then a few weeks later I took the job and I was very good at it. It made me a lot better at a lot of things, and gave me a break from things I needed a break from. I took the job I have today — as an engineering manager, again — precisely because of the product aspects it includes.)
If the ladder is what you’re after after all, success is going to depend on being open to — and soliciting! and incorporating! — good-faith feedback, even (especially) when it’s hard to hear. Insist that your manager provide direct and honest feedback, and focus your attention on feedback that is specific to you. Ask direct questions, like: “If you were me and you wanted to get promoted, what would you be doing more of? What would you be doing less of?”
Peers and mentors can be great support when you’re trying to get leveled up, but remember that they may have a limited understanding of their own strengths and weaknesses when it comes to the ladder, which can skew their perspective on “what it takes.” Again, ask for feedback that’s specific to you. “More of/less of” questions can help focus the feedback, and questions like “What’s something I could have done better in the last month?” can give people the permission they need to say what you need to hear.
Finally, to managers: I know it’s not fun to have these conversations, especially when you’re having them with someone from an under-represented group of which you are not a part, especially when you really want to see that person succeed because otherwise you’re worried you might be part of the problem. I have avoided these conversations myself, and I have watched people avoid these conversations and not pushed them to do the right thing.
You (and I) do no one any favors by extending a protective wing that shields them only as long as you’re their manager. I have seen direct, difficult feedback on this topic change the course of people’s careers for the better — often ending with the person thriving as an engineer who finally understands how to grow and thrive.
Maybe it’s useful to shift your mindset from “I want to see them succeed” to “I want them to enjoy success.” The first takes an implicitly narrow view of success: unstated is the rest of the sentence “… at what they’re trying to do.” The second focuses on a success that’s defined primarily by their enjoyment of it. Their enjoyment might actually be in climbing an engineering ladder, even when they’re a bit miserable in the moment — and they need you to help remind them of that and help them stay focused on that goal. Or their enjoyment might be in seeing ideas turn into reality on a screen you can hold in your hand — and there are a whole, whole lot of ways to work on that. Be the one with the guts to help them find their way to enjoying success, whether “engineer” is in the title or not.
* Hope for the Flowers is a cherished book from my childhood that I now see is categorized in “Christian Books & Bibles > Christian Living” and I’m not sure what to do with this new information, but I still think it’s worth owning in its paperback form.
Originally published at rmurphey.com on December 23, 2021.
