This note does not have a description yet.
Links to this note
A process for managers and senior leaders to discuss the performance across the organization with the goal of consistently and fairly applying expectations for all roles and levels. This helps to decrease the importance of individual’s personal judgment and biases—managers are more of an instrument of the performance process rather than the sole arbiter.
Below are some shapes of engineers I’ve managed in my career and what I’ve learned about them. Pattern matching based on experience is important in an experiential field like management.
With remote teams, it’s not like you can look over someone’s shoulder or visibly see if they are struggling—the only observable information is the outputs. That’s why remote team management needs to be centered around saying what you’re going to do and then comparing that to the output.
Accumulated short-term compromises and hacks in a codebase that must be paid down over time. Side effects large amounts of tech debt include decreased velocity of making changes and frequent breakages. However, used well, tech debt can increase the velocity of a team and get more done in less time.
When interviewing candidates about their experiences and challenges they have encountered, you learn a lot about their employer, how they work, and the real story behind some decisions if you listen closely.
High performing engineering teams continuously raise the bar for technical quality. Previous technical decisions are likely to not meet the current technical quality bar. Closing the gap between the two helps address tech debt and adopt a growth mindset about the team and codebase. All teams that are improving quality will notice the gap and that is to be expected. Failure to close that gap leads to more tech debt.
A manager is constantly sythesizing information into useful direction and feedback to the team.
A mission should be boiled down to a single aspirational statement that encompasses what the team actually does that’s valuable (not necessarily what leadership says they do), metrics describe the observable effects as the team succeeds in the mission.
Setting a goal around a metric that is the result of the output of other metrics and goals being driven. These second order changes are not directly worked on by the team, but expected to be achieved.
Using demos as a way of focusing on specific functionality and elevating quality. Presenting your work builds in accountability and reviewing demos provides feedback. Over time, this practice calibrates people around a set of product principles and shared context.
Focusing on continuously improving p99.9 latency (long tail latency) not only improves overall latency, it necessitates more reliable systems, better user experience, and enables more enterprise sales who tend to want contractual obligations around p50 latency.
Prior to perfomance management calibrations, each manager writes a document that briefly summarizes the performance of each person they managed during the review period. The document needs to highlight specific projects and behaviors with examples to support a facts-based discussion (reduces bias) and reasoning behind the designation decision.
An exercise to enumerate all of the ways a project could go wrong. As a prompt, imagine the project has failed, what happened and why? This helps to uncover possible issues that can be prioritized ahead of time to achieve a more certain outcome.
The reason there are far fewer engineering management blogs compared to software development blogs not because there is a small supply of managers who can write blogs, but because managers are secretly worried they are doing it completely wrong (imposter syndrome).