Today I want to talk about the space familiar to all software engineers (and likely many others outside the field), the Dreaded Impact-Effort edge. I’m talking about the unenviable position many early-career engineers find themselves in, of doing all the work, and getting none of the credit/recognition/rewards. Of feeling under-appreciated, taken for granted, of feeling like your career’s stalled and you don’t know what to do about it. Of feeling invisible.
I’ve encountered a lot of folks who’ve felt that way over the years. They tended to concern themselves with high-impact, high-effort work, and didn’t think through how visible that work was to the layers of management above. Then they wondered why they didn’t get the credit they deserved, or didn’t get the promotion they wanted.
Well… if your visibility is poor, what do you expect?
The problem, I think, is our personality. I can’t speak to other professions, but software engineering tends to attract introverts. Geeks. Nerds. We’re more comfortable manipulating computers than people. For many of us, if you locked us into our office with a challenging problem we’d be perfectly happy to spend our existence there, seeing other people only as bits on the screen.
Believe me, I understand. I was/am that way too.
There’s nothing wrong with that. If you’re okay with never making Senior/Principal.
The problem is this. At some point in your career, modulo a few notable exceptions, your impact is measured less by how much code you produce, and more by how much you up-level others. And to do that, you kind of have to embrace your inner extravert. You don’t need to become a social butterfly, but you do need to learn how to talk to people effectively, and in a way that leaves you both wanting to ever see each other again.
This is just about when the shakes start. “But I just want to code. I hate politics, and I hate dealing with people. I’ll have a beer with a colleague no problem, but trying to get them to do something? Convincing them of something?? Teaching them??? No, thank you.”
I’m exaggerating, of course. Human beings are complex, and no one metric can fit any given person. I’ve known plenty of extravert engineers. Most of the ones I’ve met are either Principals, or well on their way there. Because they can naturally project a larger scope of influence than your typical braniac introvert pounding away at their keyboard in the corner, they get the visibility and the rewards.
And please don’t think I’m devaluing lone-ranger braniacs. Most of software engineering as we know it today has been built by their efforts. They’re the (positive) workhorses of any organization, tackling the hard problems, delivering complex features on time and with high quality.
They also tend to fall smack in the middle of the career bell curve — they’re your SDE IIs, your mid-level high performers, limited in upward momentum by their inability to share their hard-learned skills with others.
My mission as a manager is to help them get past that. And to do that, I must give them opportunities for communication, for projecting their influence outward. And I must teach them that visibility is a good thing.
That Spotlight Burns!
Because most of us are introverts, visibility is anathema. “I don’t want to have to promote myself,” I often hear engineers say. “My accomplishments should stand on their own.” Self-promotion feels icky. This is the exact reverse of the Cynical Career Path. You want to do all of the hard work, and expect the credit to come on its own.
At least, most of the time. If you have a great manager they’ll watch out to make sure you get the credit you deserve. But just be aware, you’re making them do your work for you. You’re placing your career entirely in their hands, making yourself wholly dependent on their goodwill. Why would you freely give someone that much power over you?
One common issue with new engineers is the fear of looking stupid in front of their colleagues. I’ll write a post about that later, but for now just take my word that people don’t think you’re stupid for being wrong. People think you’re stupid only when you persist in being wrong in the face of facts. (Know any politicians like that?)
Don’t let fear hold you back. Don’t let your inner introvert hold you back. Sooner or later you’re going to want to advance past SDE II to Senior and beyond, and to do that you’re going to have to come out of your shell. Might as well do it now.
So how do we fix this?
As it happens, getting away from the Effort/Impact Edge is quite simple, and it involves exactly what I’d already talked about: passion for what you’re doing, and passion for evangelizing it. Let’s take a couple examples and work through how they can turn from invisible to visible:
Situation 1: The Midnight Bug (Impact-first)
You wake up in the middle of the night to an urgent call from your manager. There’s been a critical outage of a dependency service, and the company site is down. As you’re the company’s deployment expert, you’re asked to throw on your bathrobe and go fix it.
You dig into the issue, and figure out the problem is due to a regression introduced in yesterday’s ring promotion. It had actually shown up in the test ring, but the squad involved didn’t get to it in time, and the regression went to production. You spend the next two hours reverting the changes and rebooting the service, and by 3am the site is back up. You go back to sleep, and come to work the next day feeling like you’d been beaten up. Your manager gives you an appreciative nod, but other than that, the matter is closed.
The team is unaware that anything untoward happened. A company-wide email is sent To-All by the CTO asking squads to be more careful in the future. The email is, naturally, ignored. A month later, the same issue happens again.
At next annual review, your manager mentions the incident in passing, but doesn’t give you the promotion you were expecting — budget concerns.
Alternative outcome: (with visibility)
The next morning when you get into work, you draft up a detailed post-mortem email about the incident. Without publicly placing blame, you describe the set of events that led to them, and how they could’ve been prevented. You talk to your manager about what your team can do to prevent such issues in the future, and form a plan of action with the rest of the org. You drive meetings/discussions with the test team and the relevant squad and work with your manager to change the process around ring promotions, making incidents like last night’s extremely unlikely to recur.
TBH, I’m not a SaaS expert, so please don’t come after me about what the “right” way to address the issue is. My point here is simply to illustrate how taking actions like the above not only adds a huge amount of business value, but also intrinsically raises your visibility/impact/influence on the team. And, in my experience, this translates to promotions.
Situation 2: Swinging at Windmills (Effort-first)
After having spent six months on a new team sifting through their horrid codebase you’re ready to explode. Adding a feature feels like sifting through a sea of sewage. There are no style conventions, code is copy/pasted all over the place, and certain 500-line functions could teach spaghetti how to be better spaghetti.
You’ve tried talking to your manager about the issue, and she agrees that something absolutely has to be done. But weeks and then months go by, and the situation persists.
You start taking matters into your own hands. You spend several evenings cleaning up whitespace / brace placement. You refactor the most awful of the functions/classes you encounter. You rename badly-named variables. A week turns into two. You start looking a bit haggard. Your wife and kids haven’t seen you in days. You start sleeping badly, and your work output begins dropping.
Then, one Thursday evening, you get an angry email from another squad’s EM, your manager on CC, asking why you felt the need to introduce a critical regression into a class that was under their ownership, and demanding that you immediately fix the issue. You quickly see and resolve the problem — a stupid typo, made during one of these evenings when you were particularly tired — but…
…the next morning’s conversation with your manager isn’t pleasant. She says you’ve become difficult to direct, that you’re always swinging at windmills, and that you really ought to work on your prioritization skills. Instead of getting the credit you feel you deserve for putting up so much extra time to make the code better for everyone, you get a below-average review/rewards at the next review cycle.
Alternative outcome: (with visibility)
After your fruitless conversation with your manager, you decide to try a different route. You talk to a few key developers from sister squads. They agree that, yes, the codebase has gotten unmanageable. You talk to Support, and find out that the number of support incidents has been steadily rising. You talk to PM, and find out they’re frustrated that instead of building new features, several squads are almost exclusively bug-fixing.
Armed with this information, you put together a Quality Milestone proposal. You describe the business value of reducing technical debt, projected costs of such a milestone (i.e. how many engineer-weeks it would take — a calculation you do in collaboration with senior engineers on the product), and the general approach you expect to be taking. With support from PM and Support teams, as well as key engineering talent and your immediate manager, you present the proposal to your Director.
As you can imagine, the next review cycle is going to look quite different. And not just the review cycle — in the process of doing this, you’ve greatly grown your network of advocates on the team. The next time you want to push an initiative, they’ll be that much more likely to line up behind you.
Again, is a Quality Milestone the silver-bullet solution to the underlying issue? Probably not. Don’t focus as much on the specific steps in these examples as on their collaborative nature. Instead of working solo, you involve others. Instead of tackling the issues yourself, you find allies and leverage them to achieve greater effect. And by doing that, you get the visibility and the credit you desire and deserve.
I should also note that outcomes are never guaranteed. You might approach a situation collaboratively and be stopped in your tracks by specific personality issues, bureaucratic red tape, or assholes in the management chain.
Keep trying. Or switch jobs. The alternative, the giving up, is generally worse.
But my tasks never involve others!
Even the smallest tasks can be collaborative. Or shared. The trick is passion.
I can’t repeat this enough: if you’re excited about something you’ve done, or found, or read, or whatever, share it with someone! Those little bricks of connection add up to an edifice of respect you can use to achieve greater heights of influence and visibility.
Visibility is a side-effect of collaboration. Tattoo that on your forehead, next to “Nobody cares about your career as much as you do.”
Visibility can’t be a goal in itself — chasing visibility generally doesn’t work: at best, you lose the respect of your colleagues.
But without visibility, your career will stall.
So, when you’re excited about something, share it. If you see an issue, expose it. Don’t be afraid to speak up, to make your voice heard. When all’s said and done, that’s going to be the key catalyst of your career.
There you go, and necessary disclaimers
Thanks to Kurt Heston again for reviewing my scribblings.
As usual, the views above are my own, and aren’t meant to represent Adobe or Microsoft. Feel free to hit me up on Twitter @partnerinflight, comment below, or shoot me an email at firstname.lastname@example.org
Other entries in this series:
Like what you read? Want to read more? Here’s the complete list of articles so far (in suggested order of reading):