Irrational Exuberance for 08/12/2020
Hi folks,
This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.
Posts from this week:
-
The Saint-Exupéry of metrics.
-
Staff promotion packets.
-
Promotion pathologies.
The Saint-Exupéry of metrics.
Recently we were working on the engineering section of Calm's monthly All Hands meeting, and were trying to fit a recap of the past six months, and our plan for the following six months, into a seven minute slot.
Folks at Calm are frequent users of the Calm app, so it's quick to explain our user-facing work, but we weren't quite as sure how to bottle up the spirit of some of our technical investments with roughly thirty seconds per project and a full-company audience who hadn't necessarily heard much about some of the projects.
We started thinking about what it would take to boil each project down to a single well-formed metric that told the story: a target, a baseline, a trend and a timeframe. As we discussed how we should pick that single metric per project, it reminded me of the classic quote from Antoine de Saint-Exupéry:
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”
Torturing the language a bit, I think this turns into an interesting question to ask ourselves for every project we work on: What is the Saint-Exupéry metrics for this project? What is the metric which tells the whole story of why we're doing this?
One of big projects this half was moving from our apps directly sending analytics events to downstream analytics partners to instead just sending them to an internal service which decides where there ought to reside. For that project the metric became adding a new downstream analytics integration with zero changes to our mobile apps.
Another project was migrating our frontend to Next.js and TypeScript (I'm hopeful to get a Calm blog post out on this soon, but for now Dropbox's The Great CoffeScript to Typescript Migration of 2017 is pretty great and has a lot in common with our approach). There it was reducing feature lead time by a certain amount.
There were a few projects that initially were challenging to capture in a single Saint-Exupéry metrics, and that ended up being a pretty good indicator that we should spend more time agreeing on the project's underlying motivation and purpose.
Is it the case that every project is genuinely motivated by a single metric? Well, no, of course not. Almost every great project is motivated by a number of different concerns, for example our Next.js rewrite also had a number of latency goals, but I think it's usually possible to narrow down to one compelling metric that goes a surprisingly long way towards capturing the project's spirit. (And then, ya know, link out to a design document about it.)
Staff promotion packets.
This is a draft guide for staffeng.com.
Some folks think of their promotion packet as the capstone of reaching a Staff-pus role, but I’ve seen many folks succeed by taking an opposite approach: starting to write their first Staff promotion packet long before they think they’re likely to be promoted to Staff, much the way they might use a brag document. Used this way, your packet becomes the map to accomplishing your goal.
It’s likely your company will have its own format for promotion packets, and eventually you’ll need to translate your packet into that format before it’s submitted to an internal promotion committee or process, but there’s no need to rush it. You’ll spend more time relying on it as a guide than as a formal artifact for official review, so optimize for the former.
For traversing towards your Staff-plus promotion, a general template format that’s useful is:
- What are your Staff projects? What did you do? What was the project’s impact (including a well-defined goal)? What made this project complex? Keep it very short and then link out to supporting design documents
- What are the high-leverage ways you’ve improved the organization?
- Who have you mentored and through what accomplishments?
- What glue work do you do for the organization? What’s the impact of that glue work?
- Which teams and leaders are familiar with and advocates for your work? What do they value about your work? One sentence, include data (e.g. survey data) when possible
- Do you have real or perceived skill or behavior gaps that might hold you back? For each, how would you address the concern? One sentence each
It’s useful to spend some time to write out those answers yourself, but getting promoted into a leadership role isn’t a solo activity – it’s something you can only accomplish with a team of folks supporting you along the way.
The approach that I recommend for iterating on your packet is:
Answer why you’re doing this. Many folks choose not to pursue the Staff level, you should have a reason why this is important to you. If you don’t, you’re liable to find yourself in a role you don’t enjoy.
Michelle Bu warns, “My first piece of advice to engineers is that they should avoid pattern matching in ways that lead them towards work they don’t enjoy. I’m deeply energized by the work I do, partnering with teams to solve abstract modeling and design problems. It takes a certain amount of fortitude to try again and again after many rounds of feedback, and to be honest, it’s not for everyone. If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want.”
- Temper your expectations. Promotions, especially at this level, are built over quarters, halves and years. Avoid the expectation of instant results
Bring your manager into the fold. Bring the promotion packet and to your next 1:1 with your manager, and tell them that attaining a Staff promotion is a goal of yours. Review the empty packet with them, and ask them what’s missing, what to emphasize, and if they’d recommend adding steps to the workflow. You goal is to ensure they know this is something you’re interested in and to solicit their guidance on approach.
Ritu Vincent suggests, “People frequently come to me and ask, ‘What should I do next to reach Staff?’ One of the things that I tell them is to be super open and honest with your manager about what you want from your career. A mistake I made early on in my one-on-ones was telling my manager what I thought they wanted to hear, instead of what I actually felt.”
- Compile the promotion packet. Now write the packet
- Edit the promotion packet. Wait two days, reread your promotion packet and edit for content, clarity and context
- Edit the promotion packet with peers. Share your promotion packet with several trusted peers to get feedback. Peers are often better at identifying your strengths and contributions than you are, while being closer to your work than your manager might be
- Edit the promotion packet with your manager. Share your promotion packet with your manager requesting feedback. Ask for particular focus on enumerating gaps to address. Ask if you can spend time in the following 1:1 discussing the kinds of projects and opportunities to both address gaps and make the packet stronger
- Periodically review the promotion packet with your manager. Continue to review the promotion packet with your manager during your career and performance oriented 1:1s. Both you and your manager should use it to steer you towards demonstrating the promotion criteria over time. This is particularly important to do if your direct manager changes. Maintaining this sort of document and reviewing it across managers will help mitigate the loss of progress towards promotion that often occurs after a manager change
If you take a methodical approach to following this advice, then you’ll put together your first Staff promotion packet long before you’re nominated for promotion. From there, you’ll use the packet to focus your attention and your partnership with your manager towards that goal. It won’t necessarily get you there quickly, and it event might not get you there at your current company, but it will consolidate your energy on the development and work that’ll move you towards your goal.
When it finally does comes time to write your formal packet, it’ll be a matter of editing down what you’ve collected into the official template rather than an archival process of dusting through years of effort. Hopefully nothing goes awry in the promotion process, and a Staff title follows.
Promotion pathologies.
As I was working on the Staff promotion packets article, I originally included a section on "Promotion pathologies" to (attempt to) avoid when going up for a promotion to a staff-plus engineering role, but it ended up making the article less cohesive so I scrapped it there and have pulled it out here as a separate post.
I've written about some of the weird emergent behavior around promotions, but didn't address how some recurring tropes often derail individual promotion nominations.
The themes I've frequently seen block folks from getting promoted during calibration discussions are:
"Work was too easy to justify." This comes up frequently around projects that are very high impact but don't necessarily seem hard enough to justify a promotion. This is the downside of working in a previously neglected area, as often you'll spend a while cleaning out low-hanging fruit that results in major improvements but without necessarily the difficulty of a similar impact within the core business.
"But what was the impact?" This is the flipside of the first pathology. Just as you have to come to terms with impact being just one factor in these sorts of promotions, there are folks doing great work in projects that don't go very far despite their good efforts.
"But how much of that was their work?" When working within a team, particularly a team staffed with more senior or a number of similarly senior individuals on the same problem, it's hard to attribute impact across that team. This leads some teams towards doing individual projects, which is a brittle, slow and sad way for a team to work. Generally speaking I think this is aligned with company priorities of spreading their best folks across many different teams rather than consolidating them on a smaller number of team, but it certainly can work against an individual's preference to work with similarly senior folks as they reach more senior levels.
"But we can't promote everyone." Depending on the company size, there is often an explicit budget-driven quota to the number of promotions they're comfortable making or an implicit quota driven by not wanting to appear as soft evaluators by more senior management.
"But they're not like the others." Folks often use familiarity as a proxy for excellence, with predictably negative impact to the diversity of their senior levels.
"They need to maintain the level of impact." For folks who are doing great work, but may have only reached the level of obvious-promotability more recently. This usually leads to delaying a promotion for another 1-2 performance cycles.
There are certainly promotion pathologies, but these are some that I've seen come up most frequently. If you're an engineer, you can increase your chance of promotion by preparing your manager to answer these questions. If you're a manager, reviewing these questions for each promotion canidate will reduce the likelihood of delivering a disappointing surprise.
Many of these are challenging to address–that's why I didn't include recommended counter-strategies, but hopefully it's still worthwhile to be aware of them.
That's all for now! Hope to hear your thoughts on Twitter at @lethain!
|