As I moved up my company’s career ladder, my job description became more ambiguous.
I stepped back to take a look at my work, and I was surprised to find that my biggest wins hadn’t come from technical feats or shipped code. Instead, I realized that most of my success could be attributed to more subtle decisions that were never shared with my stakeholders.
This work was hard to sell to my management chain and largely went unrecognized. Fortunately, a few close colleagues noticed that projects went more smoothly when I was onboard.
It’s easy to get recognition for fighting fires, but it’s hard to get recognized for preventing fires.
This article covers some strategies for making these Staff+ superpowers understandable to the company, both so we can get rewarded for this work and demystify some of what reaching Staff+ level looks like.
What is invisible work?
To start, I’ll define invisible work to make sure we’re all on the same page. Invisible work is work that is:
- Critical to your success
- Takes skill to do well
- Is never shown to stakeholders
My background is in data science. I can confidently say that almost all of my work is invisible. Good analysis is a process of developing hypotheses and then discarding them. My client only sees my final product, polished up and ready for the showroom. I never show the pile of cracked and discarded hypotheses hidden in my workshop.
This is a good thing! I dig into a problem, understand it deeply, then simplify my understanding for my peers. If I’m doing my job well, I’m making it look easy. This can cause problems when going for promotion though.
Invisible work is by no means limited to data work. I’ve saved the company months of effort by taking an afternoon to sit on my couch and carefully write a project spec – only to decide the project isn’t worth pursuing after all. This is a triumph even if it doesn’t lead to an exciting launch.
In The Mythical Man-Month , Fred Brooks tells us to plan on throwing one away. This sacrificial prototype is important (but invisible) work.
This article is no exception. There are at least two drafts that will (thankfully) never see the light of day. I’ve also had countless conversations with mentors and peers to help develop the idea of invisible work. This pre-work is critical and underappreciated.
Why’s that a problem?
At one of my previous gigs, I got a performance review that effectively said, ‘We want to see you demonstrate more complexity in your work.’
On the surface that might sound fine, but this thinking is backward and too common in the industry. Really, what we should want are simple solutions to complex problems. The complexity of our work is a cost to bear, not something to maximize!
I’ve seen this type of pro-complexity thinking cause all sorts of dysfunctions. I’ve seen folks slip machine learning into places it doesn’t belong to get a flashy launch. Occasionally folks build long-winded and boring reports documenting every possible bit of complexity to prove how hard the problem was.
In both of these cases, we’re incentivizing complexity. In the end, you’re going to get more of what you incentivize.
Telling a good story
Deep down, most people feel like my job is cranking out technical code. I’m guilty of this myself. When I have my hands on a keyboard it feels like work. It’s reassuring.
In reality though, a lot of the work that’s critical to my success no longer matches that description. This became even more true as I moved up the IC ladder. Now stuff like making sure I’m solving the right problem is at the core of my work.
I had to convince myself and others that the core of my work changed. I found the best way to do that was by creating a clear and memorable story about what I do and why it’s hard. Once I understood this well, I was able to make better decisions about my work and convince others that it was important.
The key here was to focus on what was actually hard about my work. Sometimes it was a technical piece, but more often, it wasn’t. Was the hardest part of your last project writing the code? Or was it framing the problem well, getting buy-in, and getting a budget?
Once you have a story, focus on what outcomes you created. Don’t focus on the code you pumped out or the report you wrote. Focus on how your work changed the company. Maybe you found a team that was angry and stressed - but then you jumped in, gave direction, and left that team feeling happy and relieved. That’s awesome! You should do more of that!
I have three practical tips to help you build this story:
- Fight recency bias with snippets
- Keep a brag doc
- Practice your story until it’s smooth
Fight recency bias (with snippets)
Snippets are a habit I picked up at Google. The key here is to make a habit of summarizing your work at regular intervals. I do this every other week but some prefer to do it weekly.
Snippets are a way to collect data on yourself. Try to be specific. Include links to artifacts if you can. Try to document where you’re spending your time and energy, not just the stuff that’s obviously work.
I find that once a problem is well-framed, there’s usually an obvious solution. The hard part is getting to a well-framed problem.
However, when I look back on my work I only see the solution I came up with, not the work that went into framing the problem well. Snippets make it easy to remember where the hard and important work actually happened.
Keep a brag document
This is common advice – but that’s because it’s useful!
I keep a list of my professional successes in a Google Doc. Every time I’m excited about a project going well, I try to make a quick note of it.
This is a nice ego boost, but it’s useful too. This excitement fades quickly and it becomes hard to remember what I was excited about even a month later. When I look at my brag doc it serves as an index to my weekly snippets, showing me where to look for important work. Plus it’s a nice dopamine hit.
Work the story until it’s smooth
The first time you try telling your story, it’s going to be clunky. The only way to get past this is practice. Work your story over until it’s smooth. In the ideal case, you want this story to be able to spread by word of mouth.
I like practicing my story in my 1:1s. Usually someone asks me what I’ve been up to. This is a great chance to share what you think was actually difficult about your work this week. Replacing the usual small talk with commentary on my invisible work has sparked some great conversations with my coworkers. Pretty often there’s a flash of recognition where they realize that – yeah, that is really hard!
You’ll want to share your story with your manager too. Your manager is eventually going to be in a room with their peers arguing for why you need a promotion. If you’ve armed your manager with a great story about why your work is hard, they’re going to be grateful to you for making them look smart.
P.S.: I originally wrote this article for StaffPlus and I'm just now getting around to sharing it here.
P.P.S.: Tanya Reilly quoted this piece in "The Staff Engineer's Path" 🎉