I iterate on my process for supporting the career development of the engineers that report to me. Documenting this feels useful to me now. Hopefully this is useful to others, and I welcome feedback from engineers and engineering managers.
The objective
To build a partnership between myself and an individual contributor, so that I completely understand and support the person’s goals, trajectory, and current capabilities.
A process in 5 parts
Building cadence and trust
I don’t believe the type of proactive thinking can happen without a degree of expectations and space. I reserve the last 1:1 of the month (starting from Monday) to career development. A new engineer reporting to me doesn't quite know what to expect and this conversation often feels intimidating. Before any proactive thinking can happen, we must build rapport and trust. The best way to build this process is to start with predictability and cadence. We won’t launch into a career discussion until we’ve first had a month of 1:1s. In each conversation we build more common ground and I explain my processes to show how I think. A week before the first career conversation, I reiterate the goal is mutual understanding of the career ladder. With a full week to think it over, the conversation turns away from “What do you want out of your career?”. That scary question transforms into something simpler, “How do you interpret this document?”
Understanding the Ladder
Ladders are difficult to interpret. In a knowledge-oriented job people have different skills and different roles. Because of this, it is common for two people to read the same sentence and end with different interpretations. We hold on to the words most meaningful to us in the moment, and forget the others. Importance is subjective and transient.
The 1:1 meeting to devoted mutual understanding of the ladder is a pretty easy meeting. We start with both of us having the ladder in front of us. It doesn't matter if the ladder is on a laptop screen (if you can discipline yourself away from Slack) or printed out. We read through section by section, first the engineer talks about how they read it and what it looks like to do well. I take detailed notes, paying close attention to when their interpretation differs. Once they share their thoughts, I share my interpretation and experiences, as well as how I’ve seen it done well.
Good conversations come from the places our interpretations differ. Disagreement on a trait or behavior is rarely about whether it's important but how and where it shows up. Knowing which section to assign behaviors simplifies discussions. But sometimes people interpret things differently, and that's ok. The whole point of the exercise is to build the framing for the work completed.
Writing A career narrative in 3 parts
After we talk through the ladder, I hide behind a computer in a quiet corner and type out my understanding. This is in a Google Doc shared between myself and the engineer. I type out a personalized view of the ladder, which is a more meaningful anchor for their work. Now people think about something more specific than the generalized company-wide ladder. I share the document with them, asking to make suggestions in “Suggest” mode. This ensures that I'm notified for anything I got wrong. This document becomes our shared document to record the upcoming months. Setting a time limit is important on this document, no more than 12 months. People change and grow, and when they do their interpretation of the ladder changes.
Now we have a personalized ladder describing what the ladder means and what "good" means. There is still a bunch of empty space and empty space is scary. People dislike filling in large, open ended text blocks and it's my job to make that not scary. I have some prompts to go through. I develop prompts for each area of the ladder to ask in our monthly career 1:1 meetings. For, “Getting Things Done” I ask, “What is the most important thing you think we should get done in the next 6 months, and if we don’t will feel we wasted an opportunity?” From there we can have a conversation about their role in that work (main contributor, lead). If someone brings up something that isn’t on the team’s roadmap, it's a sign of bigger problems around team alignment and vision. This is a good opportunity to test this.
After this conversation, again I open that Google Doc in a quiet corner and begin writing down what I’ve heard. I do this in a prospective hindsight format, writing it as if it has already happened. I imagine we’re done and the work has shipped complete with happy users. It’s a bit tougher of an exercise, but has a lot of positive benefits. We revisit this document monthly and revise the prospective items. Sometimes this means dropping them entirely, or adding metrics and links to announcement emails. The document is living, updated monthly, and ends as an accurate high level overview of the work done. Bonus points because it also matches with the company's ladder. This makes writing performance reviews really, really easy.
Changelogs for yourself: Brag Docs
Julia Evans wrote about brag docs in her 2017 year in review, and they’re a tool I use and encourage for everybody. I think of them as changelogs for my growth, and it is a way for my manager and I to review what I’ve done and try to assess impact. The key is to have an exceptionally low barrier of entry for what potentially ends up in the brag doc. I have wired up an Alfred workflow that allows me to just run “did <thing>” that appends to a text file. I can review that file later and add worthy items to my brag doc with more context, or more likely scrap them if they aren’t good enough.
The ideal item in your brag doc is something done (whether alone or with other people). It should explain the context of the work and who you worked with. For example, last year I wrote a simple scheduled task that runs every Monday, finding upcoming anniversaries and sends their manager a Slack ping. The brag doc entry looked like:
I worked with $PERSON on the anniversary bot to encourage celebrations on the team. I put together a brief [linked], we iterated on copy, and successfully deployed the bot. Thanks to the help of $ENGINEER, got the bot running on our shared scheduled task infrastructure so the operating costs and overhead are negligible.
Most people forget the list of things they've done until review season arrives. This list makes it so find and assess impact! As a manager, I love this. I can take time, on my own, and discover impact. For my example, someone could look at the inventory of anniversary pins and determine if more managers are celebrating anniversaries.
The key value of the brag doc for the manager is that the manager has a starting point to assess and measure impact. Without the list, it’s easy to forget about small projects with large impact.
Writing performance reviews
Most people write self-reviews, peer reviews, and upward reviews. If you are a manager, you also write performance reviews for direct reports. This is a lot of writing and requires a heavy time commitment. By implementing an ongoing process, writing a performance review is editorializing and contextualizing. This is a much easier task, especially if you have a lot of direct reports.
Guidance for self review
Most companies have a guided self-review. Typically this collects work done and the impact, strengths, and areas for development. These empty prompts can cause anxiety, which is a reasonable response. If you break them down and use a framework it becomes less daunting, and as a manager this is part of my job.
The most suspicious area is listing your own weaknesses or areas for development. The default response is think or assume “things I’m bad at”. That’s a mistake, because the areas for development are focal points to increase more impact. Impact comes from projects, so connect development to specific projects.
I enjoy and use the phrasing, “If I were good at ________, then project would have desired outcome”. Start with answering that for each project, then look at the skills and outcomes. If there are glaring skill deficiencies, this is also the worst place to put those down. Working with your manager to overcome a gap needs to happen outside a 6 or 12 month performance check-in. As a manager, I’m super busy in this time and I won't be able to support people well enough! My goal is zero surprises on both sides.
But what about strengths? This also works best to fill in the blanks on some sentences. “By practicing __________ during project, I observed some outcome”. Some examples here:
By practicing rigorous code review practices, I observed code reviews having increased comments and more interaction before approval and merge, reducing change-related outages.
By writing (and sharing) great commit messages, I observed it was faster to identify commits when a change caused a problem.
By putting agendas in all my meetings, I observed our meetings were more effective in arriving at decisions.
It is easier to find a common theme in these lists and package them up as a strength. The strength could be an eye for technical detail, or organizing work, but at this point it should be clear. As the manager, I can figure out how to measure and assess the outcomes. This partnership means we both have ownership of the resulting in data-filled narrative.
People don't like to do work that isn't hooked up to anything since it feels like its thrown away and unimportant. Often project metrics are looked at once and never again. When metrics are inputs into performance review, the purpose becomes much clearer. There is data to tell a story from start to finish. The alternative is waiting until the very end and quickly trying to measure if you succeeded. Waiting until after the work completes is moving the goal posts.
Writing reviews for direct reports
Now that the self-review is done, the manager must write reviews. My general method for writing reviews takes an initial 20 minutes per report. I generate a list of stats and data to collect, batching that together with other reviews. The general flow looks like:
Read their ongoing career narrative document
Read their brag doc, highlighting and listing data I need to collect
Read peer reviews
Read their self-review
Build an outline and rough draft according to the review template
Pause individual reviews, collect data for all reports
Final iteration including specifics from the data collected
After I review the brag doc and career narrative, I begin writing the outline according to our format. At this point, the impact and strengths are pretty clearly defined but often lacking data. If there is any unexpected content, I flag that to bring up in our discussion of the performance review.
Managing in a high growth environment often drops managers into frenetic situations. A good thing about this process is if I'm too busy, I can scale each step down (and tell the engineer). I ensure that I can budget at least 30 minutes, though. It isn’t uncommon in a growing company that a manager will have a reporting load that consumes days. Work can't and won't stop because performance reviews are being written. I block off time on my calendar every day. My normal schedule helps me with this, too. I begin work at 7am and usually have time for focus work between 7am and 9am. Those 10 hours are critical.
Why is Career Development important?
I’m grateful for the modern research on motivation and the great RSA Animate video of Daniel Pink’s book summarizing it. Today we have a much better idea of motivation and when people do their best work. We’ve also learned how fragile this optimal state is and the things that break it. Any interruption, disruption, doubt, or concern can knock people out of doing what they do best.
My primary goal as a manager is to elicit the peak performance of the people on my team. Nobody does their best when they’re concerned and worried about their own future and what comes next. When people worry about their future they constantly search for any signs of danger. Rather than looking like highly effective engineers, they resemble meerkats in sentinel mode.
Bringing certainty, predictability, and a process to people’s careers reduces distractions. Being less distracted means being more focused. More focus increases output and quality. This high-quality high-output existence feels very good and people want to be there. It creates justifiable happiness and pride in the team. That's when my job is best.
I’m not always successful but I keep trying. The path to high quality productivity is fragile and prone to fail from external factors. I use the career narrative as a foundation to build teams on. Without this foundation, though, there is no bedrock to anchor a team. Without an anchor, an identity and expectations, is how teams fail.