Full Title: An Elegant Puzzle. Systems of Engineering Management
Highlights
There’s a saying that people don’t leave companies, they leave managers. (Location 5)
Regardless of what motivation first brings you into management, it can feel as if you’ve entered a troubled profession. Skilled practitioners are scarce, and only the exceptional company is willing to invest in growing its managers. (Location 170)
my appreciation for management, and engineering management in particular, has grown, and I’ve come to view the field as a series of elegant, rewarding, and important puzzles. (Location 186)
Organizational design gets the right people in the right places, empowers them to make decisions, and then holds them accountable for their results. Maintained consistently and changed sparingly, nothing else will help you scale more. (Location 189)
An organization is a collection of people working toward a shared goal. Each organization is an exploration of the possible, undertaken together by the ten, the hundred, or the thousand. Initially, I was tempted to glibly write that sometimes organizations work, but the truly extraordinary thing is that all organizations work. (Location 209)
organizational design is the attempt to understand why some create such energy and others create mostly heat: friction, frustration, and politics. I believe that excellent organizations grow from consistently applying a straightforward process. (Location 212)
When I have a problem that I want to solve quickly and cheaply, I start thinking about process design. A problem I want to solve permanently and we have time to go slow? That’s a good time to evolve your culture. However, if process is too weak a force, and culture too slow, then organizational design lives between those two. (Location 214)
I started to encounter a new category of problems that I had never thought about. How many teams should we have? Should we create a new team for this initiative, or ask an existing team to take it on? What is the boundary between these two teams? These questions were the gateway to the obscure art of organizational design. (Location 221)
I’ve come to believe that the fundamental challenge of organizational design is sizing teams. (Location 223)
Managers should support six to eight engineers This gives them enough time for active coaching, coordinating, and furthering their team’s mission by writing strategies, 2 leading change, 3 and so on. (Location 230)
Tech Lead Managers (TLMs). Managers supporting fewer than four engineers tend to function as TLMs, taking on a share of design and implementation work. For some folks this role can uniquely leverage their strengths, but it’s a role with limited career opportunities. To progress as a manager, they’ll want more time to focus on developing their management skills. Alternatively, to progress toward staff engineering roles, they’ll find it difficult to spend enough time on the technical details. (Location 233)
Coaches. Managers supporting more than eight or nine engineers typically act as coaches and safety nets for problems. They are too busy to actively invest in their team or their team’s area of responsibility. It’s reasonable to ask managers to support larger teams during the transition to a more stable configuration, but it is a bad status quo. (Location 237)
Managers- of- managers should support four to six managers This gives them enough time to coach, to align with stakeholders, and to do a reasonable amount of investment in their organization. On the other hand, it will also keep them busy enough that they won’t be tempted to create work for their team. (Location 240)
Managers supporting fewer than four other managers should be in a period of active learning on either the problem domain or on transitioning from supporting engineers to supporting managers. In the steady state, this can lead to folks feeling underutilized, or being tempted to meddle in daily operations. (Location 243)
Coaches. Similar to supporting a large team of engineers, supporting a large team of managers leaves you functioning purely as a problem- solving coach. (Location 246)
On- call rotations want eight engineers For production on- call responsibilities, 4 I’ve found that two- tier 24/ 7 support requires eight engineers. As teams holding their own pagers have become increasingly mainstream, this has become an important sizing constraint, and I try to ensure that every engineering team’s steady state is eight people. (Location 250)
Shared rotations. It is sometimes necessary to pool multiple teams together to reach the eight engineers necessary for a 24/ 7 on- call rotation. This is an effective intermediate step toward teams owning their own on- call rotations, but it is not a good long- term solution. (Location 254)
Small teams (fewer than four members) are not teams (Location 257)
I’ve sponsored quite a few teams of one or two people, and each time I’ve regretted it. To repeat: I have regretted it every single time. (Location 258)
An important property of teams is that they abstract the complexities of the individuals that compose them. Teams with fewer than four individuals are a sufficiently leaky abstraction that they function indistinguishably from individuals. (Location 259)
To reason about a small team’s delivery, you’ll have to know about each on- call shift, vacation, and interruption. They are also fragile, with one departure easily moving them from innovation back into toiling to maintain technical debt. (Location 261)
Keep innovation and maintenance together. A frequent practice is to spin up a new team to innovate while existing teams are bogged down in maintenance. I’ve historically done this myself, but I’ve moved toward innovating within existing teams. 5 This requires very deliberate decision- making and some bravery, but in exchange you’ll get higher morale and a culture of learning, and will avoid creating a two- tiered class system of innovators and maintainers. (Location 263)
the playbook that I’ve developed is surprisingly simple and effective: Teams should be six to eight during steady state. To create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five. Never create empty teams. Never leave managers supporting more than eight individuals. (Location 267)
most of their teams believe that they have urgent hiring needs. Should my friend spread hiring equally across the teams in need, or focus hiring on just one or two teams until their needs are fully staffed? (Location 275)
It’s fun to do initial discovery, learning from and about everyone. The rare moment when you choose to reorganize the team6 is painful, but concludes quickly. What’s much harder is keeping the faith when you’ve played your cards and need to find space for your plans to come to fruition. Staying the course is particularly fraught when it comes to growing an organization, because some teams always need more than you choose to provide. (Location 278)
When you talk about growing an organization, the conversation usually leads to hiring. While I believe that hiring is a very important approach to growing organizations, I also believe that we reach for it too often. (Location 281)
Four states of a team The framework starts with a vocabulary for describing teams and their performance within their surrounding context. (Location 287)
A team is falling behind if each week their backlog is longer than it was the week before. Typically, people are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied. (Location 289)
team is treading water if they’re able to get their critical work done, but are not able to start paying down technical debt or begin major new projects. Morale is a bit higher, but people are still working hard, and your users may seem happier because they’ve learned that asking for help won’t go anywhere. (Location 291)
A team is repaying debt when they’re able to start paying down technical debt, and are beginning to benefit from the debt repayment snowball: each piece of debt you repay leads to more time to repay more debt. (Location 294)
A team is innovating when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs. (Location 296)
Figure 2.4 Four stages of a team’s progress, from falling behind to innovating. (Location 300)
teams transition to a new state exclusively by adopting the appropriate system solution for their current state. As a manager, your obligation is to identify the correct system solution for a given transition, initiate that solution, and then support the team as best you can to create space for the solutions to work their magic. If you skip to supporting the team tactically before initiating the correct system solution, you’ll exhaust yourself with no promise of salvation. (Location 302)
When the team is falling behind, the system fix is to hire more people until the team moves into treading water. Provide tactical support by setting expectations with users, beating the drum around the easy wins you can find, and injecting optimism. (Location 308)
the system fix is to hire net new people, increasing the overall capacity of the company. Sometimes people instead attempt to capture more resources from the existing company, and I’m pretty negative on that. People are not fungible, and generally folks end up in useful places, so I’m skeptical of reassigning existing individuals to drive optimality. By nature, it’s also impossible for this kind of discussion to not become political, even when everyone involved has deep trust in and respect for each other. (Location 310)
When the team is treading water, the system fix is to consolidate the team’s efforts to finish more things, and to reduce concurrent work until they’re able to begin repaying debt (e.g., limit work in progress). Tactically, the focus here is on helping people transition from a personal view of productivity to a team view. (Location 314)
When the team is repaying debt, the system fix is to add time. Everything is already working, you just need to find space to allow the compounding value of paying down technical debt to grow. Tactically try to find ways to support your users while also repaying debt, to avoid disappearing into technical debt repayment from your users’ perspective. Especially for a team that started out falling behind and is now repaying debt, your stakeholders are probably antsy waiting for the team to start delivering new stuff, and your obligation is to prevent that impatience from causing a backslide! (Location 317)
Innovating is a bit different, because you’ve nominally reached the end of the continuum, but there is still a system fix! In this case, it’s to maintain enough slack in your team’s schedule that the team can build quality into their work, operate continuously in innovation, and avoid backtracking. Tactically, ensure that the work your team is doing is valued: the quickest path out of innovation is to be viewed as a team that builds science projects, which inevitably leads to the team being defunded. (Location 321)
I can’t stress enough that these fixes are slow. This is because systems accumulate months or years of static, and you have to drain that all away. Conversely, the same properties that make these fixes slow to fix make them extremely durable once in effect! (Location 325)
The hard part is maintaining faith in your plan— both your faith and the broader organization’s faith. At some point, you may want to launder accountability through a reorg, or maybe skip out to a new job, but if you do that you’re also skipping the part where you get to learn. (Location 328)
2.2.3 Consolidate your efforts As an organizational leader, you’ll be dealing with a number of teams, each of which is in a different place on this continuum. You’ll also have limited resources to apply, and they’ll usually be insufficient to simultaneously move every team down the continuum. Many folks try to move all teams at the same time, peanut buttering7 their limited resources, but resist that indecision- framed- as- fairness: it’s not a fair outcome if no one gets anything. (Location 333)
For each constraint, prioritize one team at a time. If most teams are falling behind, then hire onto one team until it’s staffed enough to tread water, and only then move to the next. (Location 338)
Adding new individuals to a team disrupts that team’s gelling process, so I’ve found it much easier to have rapid growth periods for any given team, followed by consolidation/ gelling periods during which the team gels. The organization will never stop growing, but each team will. (Location 340)
This approach to nurturing great organizations is the opposite of a quick fix. While it’s slow, I’ve found that it consistently leads to enduring, real improvement in the happiness and throughput of an organization. Most importantly, these improvements stick around long enough to compound, creating a durable excellence. (Location 343)
“Once a team has repaid its technical debt, shouldn’t the now surplus team members move to other teams?” This makes a lot of sense, because the team, with so little technical debt left, is now overstaffed relative to its global priority. Repeated across many teams, this could lead to an organization having far too many engineers allocated against last year’s problems, and too few against today’s. This is an important problem to address! First, let me explain why I’m skeptical of reallocating individuals to address global priority shifts, and then I’ll suggest a couple alternative approaches to this conundrum. (Location 348)
2.3.1 Team first Fundamentally, I believe that sustained productivity comes from high- performing teams, and that disassembling a high- performing team leads to a significant loss of productivity, even if the members are fully retained. In this worldview, high- performing teams are sacred, and I’m quite hesitant to disassemble them. (Location 354)
Teams take a long time to gel. When a group has been working together for a few years, they understand each other and know how to set each other up for success in a truly remarkable way. Shifting individuals across teams can reset the clock on gelling, especially for teams in the early stages of gelling, and when there are significant differences in team culture. That’s not to say that you want teams to never change— that leads to stagnation— but perhaps preserving a team’s gelled state requires restrained growth. Sometimes you will want to grow faster than a gelled team allows, and that’s okay! (Location 357)
Another reason that I lean away from moving folks off high- performing teams is that most teams have high fixed costs and relatively small variable costs: moving one person can shift an innovating team back into falling behind, and now neither team is doing particularly well. This is especially true on teams responsible for products and services. (Location 366)
There are some teams with very low fixed costs— a startup without any users, a team supporting a product that you’ve turned off entirely— and I suspect that the rules for those teams are different. I also suspect that such teams are quite uncommon in successful companies. (Location 371)
The premise of moving folks to optimize global efficiency also implies a deeper understanding of how productivity is generated than I’ve ever personally achieved. I’m a strong believer in not adding more resources to a team with visible slack, but I’m less convinced that the inverse applies. (Location 374)
The expected time to complete a new task approaches infinity as a team’s utilization approaches 100 percent, and most teams have many dependencies on other teams. Together, these facts mean you can often slow a team down by shifting resources to it, because doing so creates new upstream constraints. (Location 376)
slack, I find that teams put spare capacity to great use by improving areas within their aegis, in both incremental and novel ways. As a bonus, they tend to do these improvements with minimal coordination costs, such that the local productivity doesn’t introduce drag on the surrounding system. (Location 379)
“slackful” teams function as an organizational debugger: you don’t have to consider them when debugging the overall organizational throughput. I’ve found it much easier to work a couple constraints at a time, solving forward without needing to revisit previous constraints. (Location 381)
I’ve found it most fruitful to move scope between teams, preserving the teams themselves. If a team has significant slack, then incrementally move responsibility to them, at which point they’ll start locally optimizing their expanded workload. It’s best to do this slowly to maintain slack in the team, but if it’s a choice of moving people rapidly or shifting scope rapidly, I’ve found that the latter is more effective and less disruptive. (Location 390)
Shifting scope works better than moving people because it avoids re- gelling costs, and it preserves system behavior. Preserving behavior keeps your existing mental model intact, and if it doesn’t work out, you can always revert a workload change with less disruption than would be caused by a staffing change. (Location 394)
The other approach that I’ve seen work well is to rotate individuals for a fixed period into an area that needs help. The fixed duration allows them to retain their identity and membership in their current team, giving their full focus to helping out, rather than splitting their focus between performing the work and finding membership in the new team. This is also a safe way to measure how much slack the team really has! (Location 396)
All real- world systems have some degree of inherent self- healing properties: an overloaded database will slow down enough that someone fixes it, and overwhelmed employees will get slow at finishing work until someone finds a way to help. (Location 414)
Productively integrating large numbers of engineers is hard. Just how challenging this is depends on how quickly you can ramp engineers up to self- sufficient productivity, but if you’re doubling every six months and it takes six to twelve months to ramp up, then you can quickly find a scenario in which untrained engineers increasingly outnumber the trained engineers, and each trained engineer is devoting much of their time to training a couple of newer engineers. (Location 420)
For every additional order of magnitude of engineers, you need to design and maintain a new layer of management. For every ~ 10 engineers, you need an additional team, which requires more coordination. 14 Each engineer means more commits and deployments per day, creating load on your development tools. Most outages are caused by deployments, so more deployments drive more outages, which in turn require incident management, mitigations, and postmortems. Having more engineers leads to more specialized teams and systems, which require increasingly small on- call rotations so that your on- call engineers have enough system context to debug and resolve production issues. Consequently, relative time invested in on- call goes up. (Location 438)
at high enough rates, the marginal added value of hiring gets very slow, especially if your training process is weak. (Location 452)
the overall impact of increased load comes down to a few important trends: Most system- implemented systems are designed to support one to two orders’ magnitude of growth from the current load. Even systems designed for more growth tend to run into limitations within one to two orders of magnitude. If your traffic doubles every six months, then your load increases an order of magnitude every 18 months. (And sometimes new features or products cause load to increase much more quickly.) The cardinality of supported systems increases over time as you add teams, and as “trivial” systems go from unsupported afterthoughts to focal points for entire teams as the systems reach scaling plateaus (things like Apache Kafka, mail delivery, Redis, etc.). (Location 457)
If your company is designing systems to last one order of magnitude and is doubling every six months, then you’ll have to re- implement every system twice every three years. This creates a great deal of risk— almost every platform team is working on a critical scaling project— and can also create a great deal of resource contention to finish these concurrent rewrites. (Location 464)
the real productivity killer is not system rewrites but the migrations that follow those rewrites. Poorly designed migrations expand the consequences of this rewrite loop from the individual teams supporting the systems to the entire surrounding organization. (Location 466)
My favorite observation from The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford15 is that you only get value from projects when they finish: to make progress, above all else, you must ensure that some of your projects finish. (Location 476)
hiring and training are often a team’s biggest time investment. (Location 480)
When your company has decided that it is going to grow, you cannot stop it from growing, but, on the other hand, you absolutely can concentrate that growth, such that your teams alternate between periods of rapid hiring and periods of consolidation and gelling. Most teams work best when scoped to approximately eight engineers, as each team gets to that point, you can move the hiring spigot to another team (or to a new team). As the post- hiring team gels, eventually the entire group will be trained and able to push projects forward. (Location 481)
You can do something similar on an individual basis, rotating engineers off of interviewing periodically to give them time to recuperate. With high interview loads, you’ll sometimes notice last year’s solid interviewer giving a poor experience to a candidate or rejecting every incoming candidate. If your engineer is doing more than three interviews a week, it is a useful act of mercy to give them a month off every three or four months. (Location 485)
you start to see larger companies do major investments in both new- hire bootcamps and recurring education classes. (Location 491)
The second most effective time thief that I’ve found is ad hoc interruptions: getting pinged on HipChat or Slack, taps on the shoulder, alerts from your on- call system, high- volume email lists, and so on. The strategy here is to funnel interruptions into an increasingly small area, and then automate that area as much as possible. Ask people to file tickets, create chatbots that automate filing tickets, create a service cookbook, and so on. With that setup in place, create a rotation for people who are available to answer questions, and train your team not to answer other forms of interruptions. This is remarkably uncomfortable because we want to be helpful humans, but it becomes necessary as the number of interruptions climbs higher. (Location 495)
ownership registry, which allows you to look up who owns what, eliminating the frequent “Who owns X?” variety of question. You’ll need this sort of thing to automate paging the right on- call rotation, so you might as well get two useful tools out of it! (Location 502)
The best tool that I’ve found for this is to block out a few large chunks of time each week to focus. This can range from telecommuting on Thursday, to blocking out Monday and Wednesday afternoons, to blocking out from 8– 11 each morning. Experiment a bit and find something that works well for you. (Location 504)
the one thing that I’ve found at companies with very few interruptions and have observed almost nowhere else: really great, consistently available documentation. It’s probably even harder to bootstrap documentation into a non- documenting company than it is to bootstrap unit tests into a non- testing company, but the best solution to frequent interruptions I’ve seen is a culture of documentation, documentation reading, and a documentation search that actually works. (Location 506)
if you can keep your interfaces generic, then you are able to skip the migration phase of system re- implementation, which tends to be the longest and trickiest phase, and you can iterate much more quickly and maintain fewer concurrent versions. There is absolutely a cost to maintaining this extra layer of indirection, but if you’ve already rewritten a system twice, take the time to abstract the interface as part of the third rewrite and thank yourself later. (By the time you’d do the fourth rewrite, you’d be dealing with migrating six times as many engineers.) (Location 516)
a related antipattern is the gatekeeper pattern. Having humans who perform gatekeeping activities creates very odd social dynamics, and is rarely a great use of a human’s time. When at all possible, build systems with sufficient isolation that you can allow most actions to go forward. And when they do occasionally fail, make sure that they fail with a limited blast radius. (Location 521)
Something that is somewhat ignored a bit here is how to handle urgent project requests when you’re already underwater with your existing work and maintenance. The most valuable skill in this situation is learning to say no in a way that is appropriate to your company’s culture. (Location 529)
organizational debt. This is the organizational sibling of technical debt, (Location 535)
These are systemic problems that are preventing your organization from reaching its potential. Like technical debt, these risks linger because they are never the most pressing problem. Until that one fateful moment when they are. (Location 537)
Within organizational debt, there is a volatile subset most likely to come abruptly due, and I call that subset organizational risk. (Location 538)
What I’ve found most successful is to identify a few areas to improve, ensure you’re making progress on those, and give yourself permission to do the rest poorly. Work with your manager to write this up as an explicit plan and agree on what reasonable progress looks like. These issues are still stored with your other bags of risk and responsibility, but you’ve agreed on expectations. (Location 548)
my organizational philosophy is to stabilize team- by- team and organization- by- organization. Ensuring any given area is well on the path to health before moving my focus. (Location 553)
I try not to push risks onto teams that are functioning well. You do need to delegate some risks, but generally I think it’s best to only delegate solvable risk. If something simply isn’t likely to go well, I think it’s best to hold the bag yourself. You may be the best suited to manage the risk, but you’re almost certainly the best positioned to take responsibility. (Location 554)
As an organizational leader, you’ll always have a portfolio of risk, and you’ll always be doing very badly at some things that are important to you. That’s not only okay, it’s unavoidable. (Location 557)
Two or three years into a role, you may find that your personal rate of learning has trailed off. You know your team well, the industry particulars are no longer quite as intimidating, and you have solved the mystery of getting things done at your company. This can be a sign to start looking for your next role, but it’s also a great opportunity to build experience with succession planning. (Location 560)
Succession planning is thinking through how the organization would function without you, documenting those gaps, and starting to fill them in. It’s awkward enough to talk about that it doesn’t get much discussion, but it’s a foundational skill for building an enduring organization. (Location 563)
The first step in succession planning is to figure out what you do. This seems like it should be easy, but I’ve found it surprisingly hard! There are the obvious things you do— one- on- ones, meetings, head count planning— but you’re probably filling in a hundred little holes that you don’t even think about. (Location 566)
Take a look at your calendar and write down your role in meetings. This goes for explicit roles, like owning a meeting’s agenda, and also for more nuanced roles, like being the first person to champion others’ ideas, or the person who is diplomatic enough to raise difficult concerns. (Location 572)
Take a second pass on your calendar for non- meeting stuff, like interviewing and closing candidates. (Location 574)
Look back over the past six months for recurring processes, like roadmap planning, performance calibrations, or head count decisions, and document your role17 in each of those processes. (Location 575)
For each of the individuals you support, in which areas are your skills and actions most complementary to theirs? How do you help them? What do they rely on you for? Maybe it’s authorization, advice navigating the organization, or experience in the technical domain. (Location 577)
Audit inbound chats and emails for requests and questions coming your way. (Location 579)
If you keep a to- do list, look at the categories of the work you’ve completed over the past six months, as well as the stuff you’ve been wanting to do but keep putting off. (Location 580)
Think through the external relationships that have been important for you in your current role. What kinds of folks have been important, and who are the strategic partners that someone needs to know? (Location 582)
Take your list, and for each item try to identify the individuals who could readily take on that work. Good job, cross those out. (Location 586)
For items without someone who is ready today, identify a handful of individuals who could potentially take it over. (Location 587)
If you’re working at a well- established company, you may find that there aren’t too many gaps that couldn’t be readily filled by someone else. However, if you’re at a company going through hypergrowth, 18 it’s common to find that everyone is already working in the most complex role of their career, and you’ll uncover gaps, gaping and cavernous. (Location 589)
The first should cover the easiest gaps to close. Maybe it’ll require a written document or a quick introduction. You should be able to close one of these in less than four hours. (Location 593)
The latter will be the riskiest gaps. These are the areas where you’re uniquely valuable to the company, where other folks are missing skills, and where getting the tasks done is truly important. You’d expect closing one of these gaps to require ongoing effort over several months. (Location 595)
Write up a plan to close all of the easy gaps and one or two of the riskiest gaps. Add it to your personal goals, and then, congrats, you’ve completed a round of succession planning! (Location 598)
This isn’t a one- time tool, but rather a great exercise to run once a year to identify things you could be delegating. This helps nurture an enduring organization, and also frees up time for you to continue growing into a larger role as well. You can even get a sense of how well you’re doing by taking a two- or three- week vacation and seeing what slips through the cracks. (Location 600)
If you ask a manager about their proudest moments, they will probably tell you a story about helping someone grow. If you ask that same manager about their most challenging experience, they will probably talk about a layoff, a reorganization, a shift in company direction, or the time they weathered an economic downturn. In management, change is the catalyst of complexity. (Location 607)
The best changes often go unnoticed, moving from one moment of stability to another, with teams and organizations feeling stable at every step. The key tools for leading efficient change are systems thinking, metrics, and vision. When the steps of change are too wide, teams get destabilized, and gaps open within them. In those moments, managers create stability by becoming glue. (Location 610)
Many effective leaders I’ve worked with have the uncanny knack for working on leveraged1 problems. In some problem domains, the product management skill set2 is extraordinarily effective for identifying useful problems, but systems thinking is the most universally useful tool kit I’ve found. (Location 618)
thinking is that the links between events are often more subtle than they appear. We want to describe events causally— our managers are too busy because we’re trying to ship our current project— but few events occur in a vacuum. (Location 625)
Big changes appear to happen in a moment, but if you look closely underneath the big change, there is usually a slow accumulation of small changes. (Location 629)
These accumulations are called stocks, and are the memory of changes over time. A stock might be the number of trained managers at your company. Changes to stocks are called flows. These can be either inflows or outflows. Training a new manager is an inflow, and a trained manager who departs the company is an outflow. Diagrams in this chapter represent flows with solid dark lines. (Location 631)
The other relationship, represented in figure 3.1 by a dashed line, is an information link. This indicates that the value of a stock is a factor in the size of a flow. The link here shows that the time available for developing features depends on the number of trained managers. (Location 635)
Often, a stock outside of a diagram’s scope will be represented as a cloud, indicating that something complex happened there that we’re not currently exploring. It’s best practice to label every flow, and to keep in mind that every flow is a rate, whereas every stock is a quantity. (Location 637)
Accelerate: The Science of Lean Software and DevOp, by Nicole Forsgren, Gene Kim, and Jez Humble, 4 I’ve spent a lot of time pondering the authors’ definition of velocity. They focus on four measures of developer velocity: Delivery lead time is the time from the creation of code to its use in production. Deployment frequency is how often you deploy code. Change fail rate is how frequently changes fail. Time to restore service is the time spent recovering from defects. (Location 641)
let’s see if we can model them into a system that we can use to reason about developer productivity: Pull requests are converted into ready commits based on our code review rate. Ready commits convert into deployed commits at deploy rate. Deployed commits convert into incidents at defect rate. Incidents are remediated into reverted commits at recovery rate. Reverted commits are debugged into new pull requests at debug rate. (Location 651)
Linking these pieces together, we see a feedback loop, in which the system’s downstream behavior impacts its upstream behavior. With a sufficiently high defect rate or slow recovery rate, you could easily see a world where each deploy leaves you even further behind. (Location 658)
If your model is a good one, opportunities for improvement should be immediately obvious, which I believe is true in this case. However, to truly identify where to invest, you need to identify the true values of these stocks and flows! For example, if you don’t have a backlog of ready commits, then speeding up your deploy rate may not be valuable. Likewise, if your defect rate is very low, then reducing your recovery time will have little impact on the system. Creating an arena for quickly testing hypotheses about how things work, without having to do the underlying work beforehand, is the aspect of systems thinking that I appreciate most. (Location 661)
Once you start thinking about systems, you’ll find that it’s hard to stop. Pretty much any difficult problem is worth trying to represent as a system, and even without numbers plugged in I find them powerful thinking aids. (Location 667)
Most engineering organizations separate engineering and product leadership into distinct roles. This is usually ideal, not only because these roles benefit from distinct skills but also because they thrive on different perspectives and priorities. It’s quite hard to do both well at the same time. (Location 674)
Product management is an iterative elimination tournament, with each round consisting of problem discovery, problem selection, and solution validation. (Location 687)
Problem discovery is uncovering possible problems to work on, problem selection is filtering those problems down to a viable subset, and solution validation is ensuring that your approach to solving those problems works as cheaply as possible. (Location 689)
The first phase of a planning cycle is exploring the different problems that you could pick to solve. It’s surprisingly common to skip this phase, but that, unsurprisingly, leads to inertia- driven local optimization. Taking the time to evaluate which problem to solve is one of the best predictors I’ve found of a team’s long- term performance. (Location 694)
Users’ pain. What are the problems that your users experience? It’s useful to go broad via survey mechanisms, as well as to go deep by interviewing a smaller set of interesting individuals across different user segments. (Location 698)
Users’ purpose. What motivates your users to engage with your systems? How can you better enable users to accomplish their goals? (Location 700)
Benchmark. Look at how your company compares to competitors in the same and similar industries. Are there areas in which you are quite weak? Those are areas to consider investing in. Sometimes folks keep to a narrow lens when benchmarking, but I’ve found that you learn the most interesting things by considering both fairly similar and rather different companies. (Location 701)
Cohorts. What is hiding behind your clean distributions? Exploring your data for the cohorts hidden behind top- level analysis is an effective way to discover new kinds of users with surprising needs. (Location 704)
Competitive advantages. By understanding the areas you’re exceptionally strong in, you can identify opportunities that you’re better positioned to fill than other companies. (Location 706)
Competitive moats. Moats are a more extreme version of a competitive advantage. Moats represent a sustaining competitive advantage, which makes it possible for you to pursue offerings that others simply cannot. It’s useful to consider moats in three different ways: What do your existing moats enable you to do today? What are the potential moats you could build for the future? What moats are your competitors luxuriating behind? (Location 708)
Compounding leverage. What are the composable blocks you could start building today that would compound into major product or technical leverage10 over time? I think of this category of work as finding ways to get the benefit at least twice. These are potentially tasks that initially don’t seem important enough to prioritize, but whose compounding value makes the work possible to prioritize. A design example might be introducing to an application a new navigation scheme that better supports the expanded set of actions and modes you have today, and that will support future proliferation as well. (Bonus points if it manages to prevent future arguments about the positioning of new actions relative to existing ones!) An infrastructure example might be moving a failing piece of technology to a new standard. This addresses a reliability issue, lowers maintenance costs, and also reduces the costs of future migrations. 11 (Location 712)
Once you’ve identified enough possible problems, the next challenge is to narrow down to a specific problem portfolio. (Location 721)
Surviving the round. Thinking back to the iterative elimination tournament, what do you need to do to survive the current round? This might be the revenue that the product will need to generate to avoid getting canceled, adoption, etc. (Location 723)
Surviving the next round. Where do you need to be when the next round in order to avoid getting eliminated then? There are a number of ways (many of them revolving around quality trade- offs) to reduce long- term throughput in favor of short- term velocity. (Location 725)
Winning rounds. It’s important to survive every round, but it’s also important to eventually win a round! What work would ensure that you’re trending toward winning a round? (Location 728)
Consider different time frames. When folks disagree about which problems to work on, I find that the conflict is most frequently rooted in different assumptions about the correct time frame to optimize for. (Location 730)
Industry trends. Where do you think the industry is moving, and what work will position you to take advantage of those trends, or to at least avoid having to redo the work in the near future? (Location 733)
Return on investment. Personally, I think people often under- prioritize quick, easy wins. If you’re in the uncommon position of understanding both the impact and costs of doing small projects, then take time to try ordering problems by expected return on investment. (Location 735)
Experiments to learn. What could you learn now that would make problem selection in the future much easier? (Location 739)
Once you’ve narrowed down the problem you want to solve, it’s easy to jump directly into execution, but that can make it easy to fall in love with a difficult approach. Instead, I’ve found that it’s well worth it to take the risk out of your approach with an explicit solution validation phase. (Location 741)
Write a customer letter. Write the launch announcement that you would send after finishing the solution. Are you able to write something exciting, useful, and real? It’s much more useful to test it against your actual users than to rely on your intuition. (Location 745)
Identify prior art. How do peers across the industry approach this problem? The fact that others have solved a problem in a certain way doesn’t mean that it’s a great way, but it does at least mean it’s possible. (Location 747)
Find reference users. Can you find users who are willing to be the first users for the solution? If you can’t, you should be skeptical whether what you’re building is worthwhile. (Location 750)
Prefer experimentation over analysis. It’s far more reliable to get good at cheap validation than it is to get great at consistently picking the right solution. Even if you’re brilliant, you are almost always missing essential information when you begin designing. Analysis can often uncover missing information, but it depends on knowing where to look, whereas experimentation allows you to find problems that you didn’t anticipate. (Location 752)
Find the path more quickly traveled. The most expensive way to validate a solution is to build it in its entirety. The upside of that approach is that you’ve lost no time if you picked a good solution. The downside is that you’ve sacrificed a huge amount of time if it’s not. Try to find the cheapest way to validate. (Location 755)
Justify switching costs. What will the costs of switching be for users who move to your solution? Even if folks want to use it, high switching costs may mean that they simply won’t be able to. Test with your potential users if they’d be willing to pay the full cost of migrating to your solution instead of their existing planned work. (Location 758)
agreeing on strategy and vision has been the most effective approach that I’ve found to alignment at scale. (Location 777)
Strategies are grounded documents which explain the trade- offs and actions that will be taken to address a specific challenge. (Location 779)
Visions are aspirational documents that enable individuals who don’t work closely together to make decisions that fit together cleanly. (Location 780)
A strategy recommends specific actions that address a given challenge’s constraints. A structure that I’ve found extremely effective13 is described in Good Strategy/ Bad Strategy by Richard Rumelt, 14 and has three sections: diagnosis, policies, and actions. (Location 789)
The diagnosis is a theory describing the challenge at hand. It calls out the factors and constraints that define the challenge, and at its core is a very thorough problem statement. (Location 793)
Before you’ve even finished reading a great diagnosis, you’ll often have identified several good candidate approaches. That’s the power of a well- defined problem statement, and why it’s an important foundational element for your strategy. (Location 798)
The second step is to identify policies that you will apply to address the challenge. These describe the general approach that you’ll take, and are often trade- offs between two competing goals. (Location 800)
When you read bad guiding policies, you think, “so what?” because its found a way to justify entrenching the status quo. When you read good guiding policies, you think, “Ah, that’s really going to annoy Anna, Bill, and Claire,” because the approach takes a clear stance on competing goals. (Location 805)
When you apply your guiding policies to your diagnosis, you get your actions. Folks are often comfortable with hard decisions in the abstract, but struggle to translate policies into the specific steps to implement them. This is typically the easiest part to write, but publishing it and following through with it can be a significant test of your commitment. (Location 807)
When you read good, coherent actions, you think, “This is going to be uncomfortable, but I think it can work.” When you read bad ones, you think, “Ah, we got afraid of the consequences, and we aren’t really changing anything.” (Location 811)
Because strategies are specific to a given problem, it’s okay— and even encouraged— to write quite a few of them. Over the past year, I’ve worked with people on strategies for how we partner with other teams, how we manage end- to- end API latency, and how we manage infrastructure costs. (Location 813)
People sometimes describe strategy as artful or sophisticated, but I’ve found that the hardest part of writing a good strategy is pretty mundane. You must be honest about the constraints that are making the challenge difficult, which almost always include people and organizational aspects that are uncomfortable to acknowledge. (Location 818)
If strategies describe the harsh trade- offs necessary to overcome a particular challenge, then visions describe a future in which those trade- offs are no longer mutually exclusive. An effective vision helps folks think beyond the constraints of their local maxima, and lightly aligns progress without requiring tight centralized coordination. (Location 822)
You should be writing from a place far enough out that the error bars of uncertainty are indisputably broad, where you can focus on the concepts and not the particulars. Visions should be detailed, but the details are used to illustrate the dream vividly, not to prescriptively constrain its possibilities. (Location 825)
Vision statement: A one- or two- sentence aspirational statement to summarize the rest of the document. This is your core speaking point, which you will repeat at each meeting, planning period, and strategy review. It shouldn’t try to capture every detail of your vision, but it does need to memorably evoke your vision effectively. (Location 828)
Value proposition: How will you be valuable to your users and to your company? What kinds of success will you enable them to achieve? There is a sequencing question of whether you should start with capabilities (the next bullet) and reason into value proposition or do the opposite, but I’ve found that starting from your users leads to visions that are both more ambitious and more grounded. (Location 831)
Capabilities: What capabilities will the product, platform, or team need in order to deliver on your value proposition? (Location 834)
Solved constraints: What are the constraints that you’re limited by today, but that in the future you’ll no longer be constrained by? (Location 837)
Future constraints: What are the constraints that you expect to encounter in this wonderful future? Hopefully, these new constraints will be things that are easy to adjust, like funding or hiring. (Location 839)
Reference materials: Link all the existing plans, metrics, updates, references, and documents into an appendix for those who want to understand more of the thinking that went into the vision. (Location 841)
Narrative: Once you’ve written the previous sections, the last step of writing a compelling vision is to synthesize all those details into a short— maybe one- page— narrative that serves as an easy- to- digest summary. In your final document, this is probably the second section, following the statement. (Location 844)
document that is a guiding hand to align decisions yet still creates room for teams to make their own choices and trade- offs along the way. You’ll know a vision is succeeding when people reference the document to make their own decisions, and you’ll know it’s struggling when decisions keep happening that don’t fit into its direction. (Location 847)
Test the document! This is a core leadership tool, and your first version will almost certainly be bad. Write a draft, sit down with a few different folks to get their perspectives, then iterate. Keep doing this until you’ve synthesized feedback. If there is feedback you disagree with, embrace the vision as an opportunity to address conflict by explicitly acknowledging disagreements within the vision text. (Location 852)
Refresh periodically. Take some time every year to refresh the vision, and prefer usefulness over consistency. If your old vision doesn’t resonate, it’s okay to start over: it’s a sign that you’ve learned a lot over the past year. (Location 856)
Use present tense. This makes the writing impactful and concise, and conveys a sense of confidence about the future. (Location 858)
Write simply. Often, visions are saturated with buzzwords, which turns readers off. (Location 859)
one vision for every complete distinct area, but no more. If areas overlap, you get the alignment value from having one unified vision; having two clearly articulated visions in one place is worse than having zero. (Location 860)
if your team is struggling to align with stakeholders, or if you’re struggling to lead a cohesive organization, these documents are exceptionally useful, fairly quick to write as you gain practice, and low risk (at worst, they get ignored). (Location 864)
There is a moment in every company’s growth when top- level planning shifts from discussing specific projects to talking about goals. This happens recursively across each scope of leadership, as areas of accountability become too broad or complex for their leaders to consistently understand every project’s details. (Location 867)
Bad goals are indistinguishable from numbers. “Our p50 build time will be below two seconds,” or “We’ll finish eight large projects.” You’ll know a goal is just a number when you read it and aren’t sure if it’s ambitious or whether it matters. (Location 872)
Good goals are a composition of four specific kinds of numbers: A target states where you want to reach. A baseline identifies where you are today. A trend describes the current velocity. A time frame sets bounds for the change. (Location 874)
The two tests of an effective goal are whether someone who doesn’t know much about an area can get a feel for a goal’s degree of difficulty, and whether afterward they can evaluate if it was successfully achieved. If you define all four aspects, typically your goal will fulfill both criteria. (Location 881)
There are two particularly interesting kinds of goals: investments and baselines. Investments describe a future state that you want to reach, and baselines describe aspects of the present that you want to preserve. (Location 884)
The best way to avoid such unintended outcomes is to pair your investment goals with baseline metrics, sometimes referred to as countervailing metrics. (Location 889)
Baseline metrics are useful for narrowing the solution space that you explore in order to accomplish your investment goals. They are also useful for identifying when you should pause pursuing your goals and instead invest in platform quality. (Location 893)
Although your baselines will often be about preserving a current property, you can also decide to accept some degradation before you want to trigger reprioritization. Perhaps you’re okay with costs increasing by 10 percent as long as your investment goals are accomplished. This kind of upfront clarity around trade- offs can be quite powerful. (Location 896)
The most common way to use goals is during a planning process. By agreeing on the mix of investment and baseline goals for each team, you’re able to set clear expectations for a team while still giving them full ownership of how they’ll satisfy the constraints. I’ve found that you should specify as few investment goals as possible, maybe three, and that those should be the focus of planning discussions. (Location 900)
You’ll probably want to identify more baseline goals than investment goals, but it’s easiest to separate them out to avoid bogging down the conversation. Ideally, baselines are carried over across planning periods, such that they frame the investment goals but don’t require too much active discussion during any given planning cycle. (Location 903)
Although people often talk about goals and metrics18 when they’re writing new plans or reflecting on past plans, my fondest memories of metrics are when I’ve seen them used to drive large organizational change. In particular, I’ve found metrics to be an extremely effective way to lead change with little or no organizational authority, and I wanted to write up how I’ve seen that work. (Location 913)
It enables a company to concurrently maintain many baseline metrics without overloading its teams. This is largely because this approach focuses on driving targeted change within the key drivers, only requiring involvement from a small subset of teams for any given metric. The approach is also effective because it tries to minimize top- down orchestration in favor of providing information to encourage teams themselves to adjust priorities. (Location 964)
Migrations are both essential and frustratingly frequent as your codebase ages and your business grows: most tools and processes only support about one order of magnitude of growth22 before becoming ineffective, so rapid growth makes migrations a way of life. (Location 978)
The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over- designed. 23 (Location 981)
Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt. (Location 986)
Engineers hate technical debt. If there is an easy project that they can personally do to reduce tech debt, they’ll take it on themselves. (Location 987)
this leads to a dynamic in which there is very little low- hanging fruit to reduce technical debt, and most remaining options require many teams working together to implement them. The result: migrations. (Location 989)
Each migration aims to create technical leverage (Your indexes no longer have to fit on a single server!) or reduce technical debt (Your acknowledged writes are guaranteed to persist a master failover!). They occupy the awkward territory of reduced immediate contribution today in exchange for more capacity tomorrow. (Location 991)
This makes migrations controversial to schedule, and as your systems become larger, they become more expensive. Lore tells us that Googlers have a phrase, “running to stand still,” to describe a team whose entire capacity is consumed in upgrading dependencies and patterns, such that the group can’t make forward progress on the product/ system they own. (Location 993)
Migrations are the only mechanism to effectively manage technical debt as your company and code grow. If you don’t get effective at software and system migrations, you’ll end up languishing in technical debt. (Location 998)
The good news is that while migrations are hard, there is a pretty standard playbook that works remarkably well: de- risk, enable, then finish. (Location 1001)
The first phase of a migration is de- risking it, and to do so as quickly and cheaply as possible. Write a design document and shop it with the teams that you believe will have the hardest time migrating. Iterate. Shop it with teams who have atypical patterns and edge cases. Iterate. Test it against the next six to twelve months of roadmap. Iterate. (Location 1003)
the next step is to embed into the most challenging one or two teams, and work side by side with those teams to build, evolve, and migrate to the new system. Don’t start with the easiest migrations, which can lead to a false sense of security. Effective de- risking is essential, because each team who endorses a migration is making a bet on you that you’re going to get this damn thing done, and not leave them with a migration to an abandoned system that they have to revert to. If you leave one migration partially finished, people will be exceedingly suspicious of participating in the next. (Location 1006)
Once you’ve validated the solution that solves the intended problem, it’s time to start sharpening your tools. Many folks start migrations by generating tracking tickets for teams to implement, but it’s better to slow down and build tooling to programmatically migrate the easy 90 percent. 24 This radically reduces the migration’s cost to the broader organization, which increases the organization’s success rate and creates more future opportunities to migrate. (Location 1012)
Once you’ve handled as much of the migration programmatically as possible, figure out the self- service tooling and documentation that you can provide to allow teams to make the necessary changes without getting stuck. The best migration tools are incremental and reversible: folks should be able to immediately return to previous behavior if something goes wrong, and they should have the necessary expressiveness to de- risk their particular migration path. Documentation and self- service tooling are products, and they thrive under the same regime: sit down with some teams and watch them follow your instructions, then improve them. Find another team. Repeat. Spending an extra two days intentionally making your documentation clean and your tools intuitive can save years in large migrations. Do it! (Location 1017)
The last phase of a migration is deprecating the legacy system that you’ve replaced. This requires getting to 100 percent adoption, and that can be quite challenging. (Location 1024)
Start by stopping the bleeding, which is ensuring that all newly written code uses the new approach. That can be installing a ratchet in your linters, 25 or updating your documentation and self- service tooling. This is always the first step, because it turns time into your friend. Instead of falling behind by default, you’re now making progress by default. (Location 1025)
now you should start generating tracking tickets, and set in place a mechanism which pushes migration status to teams that need to migrate and to the general management structure. It’s important to give wider management context around migrations because the managers are the people who need to prioritize the migrations: if a team isn’t working on a migration, it’s typically because their leadership has not prioritized (Location 1029)
you’re pretty close to complete, but you have the long tail of weird or unstaffed work. Your tool now is: finish it yourself. It’s not necessarily fun, but getting to 100 percent is going to require the team leading the migration to dig into the nooks and crannies themselves. (Location 1032)
My final tip for finishing migrations centers around recognition. It’s important to celebrate migrations while they’re ongoing, but the majority of the celebration and recognition should be reserved for their successful completion. (Location 1035)
at quickly growing companies, there are two managerial skills that have a disproportionate impact on your organization’s success: making technical migrations cheap, and running clean reorganizations. (Location 1039)
managing organizational change is more general, so let’s work through a lightly structured framework for (re) designing an engineering organization. (Location 1042)
My approach for planning organization change: Validate that organizational change is the right tool. Project head count a year out. Set target ratio of management to individual contributors. Identify logical teams and groups of teams. Plan staffing for the teams and groups. Commit to moving forward. Roll out the change. (Location 1044)
There are two best kinds of reorganizations: The one that solves a structural problem. The one that you don’t do. There is only one worst kind of reorg: the one you do because you’re avoiding a people management issue. (Location 1054)
My checklist for ensuring that a reorganization is appropriate: Is the problem structural? Organization change offers the opportunity to increase communication, reduce decision friction, and focus attention; if you’re looking for a different change, consider if there’s a more direct approach. Are you reorganizing to work around a broken relationship? Management is a profession where karma always comes due, and you’ll be better off addressing the underlying issue than continuing to work around it. Does the problem already exist? It’s better to wait until a problem actively exists before solving it, because it’s remarkably hard to predict future problems. Even if you’re right that the problem will occur, you may end up hitting a different problem first. Are the conditions temporary? Are you in a major crunch period or otherwise doing something you don’t anticipate doing again? If so, then it may be easier to patch through and rethink on the other side, and avoid optimizing for a transient failure mode. (Location 1056)
The first step of designing the organization is determining its approximate total size. I recommend reasoning through this number from three or four different directions: 1. An optimistic number based on what’s barely possible. 2. A number based on the “natural size” of your organization, if every team and role was fully staffed. 3. A realistic number based on historical hiring rates. Then merge those into a single number. (Location 1067)
Unless you’ve changed something meaningful in your process, it’s likely that the historical trend will hold accurate, and you should weight that figure the most heavily (and my sense is that the list of easy changes that significantly after hiring outcomes is short). (Location 1072)
One of the goals of using the year- out head count number is to avoid optimizing too heavily for your exact current situation and the current individuals you’re working with. Organizational change is so disruptive to so many people that I’ve increasingly come to believe you should drive organizational design from the boxes and not from the key individuals. (Location 1074)
Once you have your head count projection, you need to identify how many individuals you want each manager to support. (Location 1078)
If engineering managers are expected to do hands- on technical work, then their teams should likely be three to five engineers (Location 1080)
Otherwise, targeting five to eight engineers, depending on experience level, is pretty typical. If you’re targeting more than eight engineers per manager, then it’s worth reflecting on why you believe your managers can support a significantly higher load than industry average: Are they exceptionally experienced? Are your expectations lower than typical? (Location 1082)
Suppose that you have 35 engineers and 7 engineers per manager. 35 / 7 = 5 managers Log 7( 35) ≈ 1.8 managers of managers, or second- degree managers In a growing company, you should generally round up the number of managers, as this is a calculation “at rest,” and your organization will be a living, evolving thing. (Location 1088)
Once you’ve grounded yourself, here are some additional considerations: Can you write a crisp mission statement for each team? Would you personally be excited to be a member of each of the teams, as well as to be the manager of each of those teams? Put teams that work together (especially poorly) as close together as possible. This minimizes the distance for escalations during disagreements, allowing arbiters to have sufficient context. Also, most poor working relationships are the by- product of information gaps, and nothing fills those faster than proximity. Can you define clear interfaces for each team? Can you list the areas of ownership for each team? Have you created a gap- less map of ownership, such that each responsibility is owned by a team? Try to avoid implicitly creating holes of ownership. If you need to create explicit holes of ownership, that’s a better solution (essentially, defining unstaffed teams). Are there compelling candidate pitches for each of those teams? As always, are you over- optimizing on individuals versus establishing a sensible structure? (Location 1094)
With your organization design and head count planning, you can roughly determine when you’ll need to fill each of the technical and management leadership positions. (Location 1108)
four sources of candidates to staff them: Team members who are ready to fill the roles now. Team members who can grow into the roles in the time frame. Internal transfers from within your company. External hires who already have the skills. (Location 1110)
you want people who already know your culture and because reorganizations that depend on yet- to- be- hired individuals are much harder to pull off successfully. (Location 1115)
I’d recommend having a spreadsheet listing every single person’s name, their current team, and their future team. Accidentally missing someone is the cardinal sin of reorganization. (Location 1116)
A few questions to ask yourself before you decide to fully commit: Are the changes meaningful net positive? Will the new structure last at least six months? What problems did you discover during design? What will trigger the reorg after this one? Who is going to be impacted most? After you’ve answered those questions, make sure to get not only your own buy- in but also buy- ins from your peers and leadership. (Location 1119)
The final, and oftentimes most awkward, phase of a reorganization is its rollout. There are three key elements to a good rollout: Explanation of reasoning driving the reorganization. Documentation of how each person and team will be impacted. Availability and empathy to help bleed off frustration from impacted individuals. (Location 1128)
Discuss with heavily impacted individuals in private first. Ensure that managers and other key individuals are prepared to explain the reasoning behind the changes. Send an email out documenting the changes. Be available for discussion. If necessary, hold an organization all- hands, but probably try not to. People don’t process well in large groups, and the best discussions take place in small rooms. Double down on doing skip- level one- on- ones. (Location 1133)
an organization is both (1) a collection of people and (2) a manifestation of an idea separate from the individuals comprising it. You can’t reason about organizations purely from either direction. (Location 1140)
Controls are the mechanisms that you use to align with other leaders you work with, and they can range from defining metrics to sprint planning (although I wouldn’t recommend the latter). (Location 1149)
Some of the most common controls that I’ve seen and used: Metrics26 align on outcomes while leaving flexibility around how the outcomes are achieved. Visions27 ensure that you agree on long- term direction while preserving short- term flexibility. Strategies28 confirm you have a shared understanding of the current constraints and how to address them. Organization design allows you to coordinate the evolution of a wider organization within the context of sub- organizations. Head count and transfers are the ultimate form of prioritization, and a good forum for validating how organizational priorities align across individual teams. Roadmaps align on problem selection and solution validation. Performance reviews coordinate culture and recognition. (Location 1152)
I’ll do it. Stuff that I will personally be responsible for doing. When you’re going to do something, it’s better to be explicit and avoid confusion on responsibilities. Best used sparingly. Preview. I’d like to be involved early and often. This is probably an area where we aren’t quite on the same page and this will help us avoid redoing work. Review. I’d like to weigh in before it gets published or fully rolled out, but we’re pretty aligned on the topic. Notes. Projects I’d like to follow but don’t have much I can add to. Often used for wide- reaching initiatives on which we are well aligned, and I want to be able to represent my colleagues’ work correctly. No surprises. The work that we’re currently aligned on but requires updates to keep my mental model in tact. If I’m asked about a related problem, I want to be able to answer it correctly. This is particularly important for me, as my effectiveness is evaluated based on my ability to stay on top of new problems. Let me know. We’re well aligned on this, since my colleagues have done it before and done it well. I want them to let me know if something comes up that I can help with, but otherwise I’m totally confident it’ll go well, so we don’t need to talk about this much. (Location 1167)
Combine your controls and the degree of alignment for each, and you’ve established the interface between you and the folks you support. This reduces the ambiguity of how you work together and allows everyone to focus. It’s useful for agreeing on performance goals, and is also very useful for exposing alignment gaps between you and individuals you work with (Location 1179)
this is a useful diagnostic for you as a leader to identify if you are micromanaging. If you simply can’t imagine a world where you don’t preview everyone’s work, it’s probably time to reflect a bit on what’s holding you back from letting the team thrive. (Location 1182)
A peculiar challenge of management is trying to invest in someone’s career development when they themselves are uncertain about their goals. As a manager, you may have more experience and more access to opportunities within the company, but that represents a small slice of someone’s career possibilities. Our schooling often rewards us for being methodical, linear thinkers, but that approach is less effective outside the intentionally constrained possibility spaces. The options for approaching a career, particularly for those of us privileged to work in technology, are so extraordinarily vast that exploring them effectively requires a different approach. This vastness also means that you, as a manager, can’t simply give folks a career path: you’ll inevitably steer them toward the most obvious avenues and through avoidable competition. (Location 1186)
it’s also quite challenging to plan your own career. I sometimes find myself walking from one meeting where I’m coaching someone on their career goals, straight into a second meeting where I struggle to string together words to articulate my own. The hardest bit is that most folks are always at the furthest point in their career, each change a step into the unknown, with limited visibility into the upcoming opportunities that their company can provide. The intersection that I’ve found between the individual’s and their manager’s perspective is the career narrative. (Location 1192)
prototypical head of engineering will be skilled at organizational design, process design, business strategy, recruiting, mentoring, coaching, public speaking, and written communication. They’ll also have a broad personal network and a broad foundation from product engineering to infrastructure engineering. That’s not even a particularly complete list of relevant skills! There are so many different aspects to build out, and you can find opportunities to practice all of them in your current role. There’s no need to convince yourself that your current role is holding you back— everything you need is here. (Location 1211)
while generalized career paths won’t necessarily align cleanly with your goals, they are also unlikely to take full advantage of your strengths. An important part of setting your goals is developing areas you’re less experienced in to maximize your global success, but it’s equally important to succeed locally within your current environment by prioritizing doing what you do well. (Location 1216)
Managers tend to have a strong sense of the business’s needs, and that gives them the superpower of finding the intersection of your interests and the business’s priorities. That translation is a creative pursuit, so don’t leave this entirely to your manager: participate as well! Brainstorm projects, research how folks at other companies have pursued similar goals, and educate your manager on aspects of your goals that they don’t know much about. (Location 1223)
Bringing your list of goals to this discussion helps ensure that it’s successful. If you don’t bring a rough draft, by default you’ll get steered toward the contested commons, and your career narrative will be a dull instrument for progress. (Location 1228)
This refined list of goals, aligned to your company’s priorities, then becomes a central artifact for how you and your manager collaborate on your career evolution. Every quarter or so, take some time to refresh the document and review it together. (Location 1230)
If you’re unconvinced that it’s worth your time to write a career narrative, you certainly don’t have to write one. Most folks get away with not writing one for their entire career and have deeply fulfilling careers despite the absence. (Location 1232)
if you don’t, then there is probably no one guiding your career. Chasing the next promotion is at best a marker on a mass- produced treasure map, with every shovel and metal detector re- covering the same patch. Don’t go there. Go somewhere that’s disproportionately valuable to you because of who you are and what you want. (Location 1234)
The three rules for speaking with the media: Answer the question you want to be asked. If someone asks a very difficult or challenging question, reframe it into one that you’re comfortable answering. Don’t accept a question’s implicit framing, but instead take the opportunity to frame it yourself. Don’t Think of An Elephant by George Lakoff 32 is a phenomenal, compact guide to framing issues. Stay positive. Negative stories can be very compelling. They are quite risky, too! As an interviewee, find a positive framing and stick to it. This is especially true when it comes to competitors and controversy. Speak in threes. Narrow your message down to three concise points, make them your refrain, and continue to refer back to your three speaking points. (Location 1240)
spent a lot of time trying to find my leadership style. Recently, I think it’s more useful to think about growing yourself as a leader by developing a range of styles and applying them thoughtfully to your circumstances. Confining yourself to one style is just too hard. (Location 1251)
One of the trickiest, and most common, leadership scenarios is leading without authority, and I’ve written about one of the styles that I’ve found surprisingly effective in those conditions. I call it Model, Document, Share. (Location 1254)
Don’t publicize it, don’t make a big deal about it, just start doing it with your team. Frame it as a short experiment with the team, and start trying it. Keep iterating on it until you’re confident it works. Have the courage to keep at it for a while, and also the courage to stop doing it if it doesn’t work after a month or two. Use the team’s health and throughput metrics to ground your decision about whether it’s working. Document. After you’ve discovered an effective approach, document the problem you set out to solve, the learning process you went through, and the details of how another team would adopt the practice for themselves. Be as detailed as possible: make a canonical document, and even get a few folks on other teams to check that it’s readable from their perspective. Share. The final step is to share your documented approach, along with your experience doing the rollout, in a short email. Don’t ask everyone to adopt the practice, don’t lobby for change, just present the approach and your experience following it. You’ll spend the majority of your time refining approaches that work effectively for your team, a bit of your time documenting how you did it, and almost no time trying to convince folks to change their approach. Strangely, in my experience, this has often led to more adoption than top- down mandates have. (Location 1268)
Mandates assume: It’s better to adopt a good- enough approach quickly. Teams have the bandwidth to adopt a new approach. The organization has available resources to coordinate a rollout. You want to centralize decision- making on this topic. Consistency is important; all teams need to approach this problem in the same way. It’s important to make this change quickly. (Location 1281)
Model, Document, Share assumes: It’s better to adopt a great approach slowly. Some teams don’t have the bandwidth to adopt a new approach. The organization may not have resources to coordinate a rollout. You want to decentralize decision- making on this topic. Teams have agency to adopt the appropriate practices for themselves. It’s okay to approach change gradually. (Location 1286)
In small organizations, it’s easy for individuals to be aware of what others are doing and to remember how they’ve previously approached similar problems. This hive mind and memory create decision- making whose consistency correlates strongly with quality. As organizations grow, there is a subtle slide into inconsistency, which is often one of the most challenging aspects of evolving from a small team into a much larger one. (Location 1299)
The two most common flavors of this I’ve seen are “product reviews” to standardize product decisions and the “architecture group” to encourage consistent technical design. There are hundreds of varieties, and they crop up wherever decisions are made. (Location 1305)
These groups typically consolidate significant authority from the broader community into the hands of a few. Many folks will feel a significant loss of freedom when you create these groups, as their zone of decision- making will be newly limited. Less obviously, many folks find the creation of centralized groups to be extremely empowering. The difference? One group is largely populated by individuals comfortable with self- authorization, and the latter typically have a higher threshold for self- authorization. (Location 1312)
A positive freedom is the freedom to do something, for example the freedom to pick a programming language you prefer. A negative freedom is the freedom from things happening to you, for example the freedom not to be obligated to support additional programming languages, even if others would greatly prefer them. (Location 1318)
How are you shifting freedoms, and who are you shifting them from? Particularly in cases where ownership is extremely diffuse, I believe that cautiously authoritative groups do increase net positive freedom for individuals without greatly reducing negative freedom. That also happens to be my goal when designing a new group! (Location 1321)
Now that you’ve decided to create a decision- making group, it’s time to get into the choices! (Location 1324)
Influence. How do you expect this group to influence results? Will they be an authoritative group that makes binding decisions? Will you rely on the natural authority of the members you select? Will they primarily work through advocacy? The answers to these questions along with the particular folks in the group, will be the primary factor in how your group impacts the positive and negative freedoms of those they work with. (Location 1325)
Interface. How will other teams interact with this team? Will they submit tickets, send emails, attend a weekly review session? Will you be reviewing work before it launches, or previewing designs before they’re staffed? Depending on the kind of influence they’re exerting and how your company works, you’ll want to play around with different approaches. (Location 1329)
Size. How large should the group be? If it’s six or fewer individuals, it’s possible for them to gel into a true team, one whose members know each other well, work together closely, and shift a significant portion of their individual identities into the team. If the group has more than ten members, you’ll find it hard to even have a good discussion, and it’ll need to be structured into sub- groups to function well (rotation that spreads members over time, working groups of some members to focus on particular topics, and so on). The larger the group, the more responsibility becomes diffuse, and the more you’ll need to have specified roles within the group, for example a member responsible for coordinating members’ focus. (Location 1332)
Time commitment. How much time will members spend working in this group? Will this be their top priority, or will they still primarily be working on other projects? Higher time commitment correlates with more actions and decisions. Consequently, my sense is that you want time commitment to be higher for areas where folks are directly impacted by the consequences of their decisions, and to be lower for scenarios with weaker feedback loops. (Location 1337)
Identity. Should members view their role in the group as their primary identity? Should they continue to identify primarily as members of their existing team? You’ll need a small team and high time commitment to support individuals shifting their identity. (Location 1340)
Selection process. How will you select members? I’ve found the best method to be a structured selection process, 35 in which you identify the requirements to be a member and the skills that you believe will be valuable, and then allow folks to apply. Membership in these groups often becomes an important signal of organizational status, which makes having a consistent process for selecting membership especially important. (Location 1343)
Length of term. How long will members serve? Are these permanent assignments, or are they fixed terms for, say, six months? If they are fixed terms, are folks eligible for subsequent elections? Is there a term limit? I’ve tried most combinations, and my sense is that the best default is fixed terms, while allowing current individuals to remain eligible, and without enacting term limits. (Location 1347)
Representation. How representative will this group be? Will you explicitly select folks based on their teams, tenure, or seniority, or will you allow clusters? Attention to this can help you avoid architecture reviews that are missing front- end and product engineers, as well as product reviews without infrastructure perspective. (Location 1350)
it’s worth talking about the four ways these groups consistently fail. They tend to be domineering, bottlenecked, status- oriented, or inert. Domineering groups significantly reduce individuals’ negative and positive freedoms, and become churn factories for members. This is most common when those making decisions are abstracted from the consequences of the decisions, e.g., architecture groups in which the members write little code. Bottlenecked groups tend to be very helpful, but are trying to do more then they’re actually able to do. These groups get worn down, and either burn out their members or create a structured backlog to avoid burning themselves out, which ends up seriously slowing down folks who need their authority. Status- oriented groups place more emphasis on being a member of the group than on the group’s nominal purpose. The value of the group revolves around recognition rather than contribution, leading to folks who try to join the group for status, and the diffusion of whatever original mission the group set out to resolve. Inert groups just don’t do much of anything. Typically, these are groups whose members have not gelled or are too busy. On the plus side, this is by far the most benign of the four failure modes— but you’re also missing out on a great deal of opportunity! Having experienced each of these a few times, I try to ensure that there is a manager embedded into every centralized group, and that the manager is responsible for iterating on the format to dodge these pitfalls. (Location 1357)
I’ve picked up some tips that I hope will help you prepare for your next presentation: Communication is company- specific. Every company has different communication styles and patterns. Successful presenters probably can’t tell you what they do to succeed, but if you watch them and take notes, you’ll identify some consistent patterns. Each time you watch individuals present to leadership, study their approach. (Location 1383)
Start with the conclusion. Particularly in written communication, folks skim until they get bored and then stop reading. Accommodate this behavior by starting with what’s important, instead of building toward it gradually. (Location 1386)
Frame why the topic matters. Typically, you’ll be presenting on an area that you’re intimately familiar with, and it’s probably very obvious to you why the work matters. This will be much less obvious to folks who don’t think about the area as often. Start by explaining why your work matters to the company. (Location 1388)
Everyone loves a narrative. Another aspect of framing the topic is providing a narrative of where things are, how you got here, and where you’re going now. This should be a sentence or two along the lines of, “Last year, we had trouble closing several important customers due to concerns about our scalability. We identified our databases as our constraints to scaling, and since then our focus has been moving to a new sharding model that enables horizontal scaling. That’s going well, and we expect to finish in Q3.” (Location 1391)
Prepare for detours. Many forums will allow you to lead your presentation according to plan, but that is an unreliable prediction when presenting to senior leadership. Instead, you need to be prepared to lead the entire presentation yourself, while being equally ready for the discussion to derail toward a thread of unexpected questions. (Location 1395)
Answer directly. Senior leaders tend to be indirectly responsible for wide areas, and frequently pierce into areas to debug problems. Their experience “debug piercing” tunes their radar for evasive answers, and you don’t want to be a blip on that screen. Instead of hiding problems, use them as an opportunity to explain your plans to address them. (Location 1398)
Deep in the data. You should be deep enough in your data that you can use it to answer unexpected questions. This means spending time exploring the data, and the most common way to do that is to run a thorough goal- setting exercise. 38 (Location 1401)
Derive actions from principles. One of your aims is to provide a mental model of how you view the topic, allowing folks to get familiar with how you make decisions. Showing you are “in the data” is part of this. The other aspect is defining the guiding principles you’re using to approach decisions. (Location 1403)
Discuss the details. Some executives test presenters by diving into the details, trying to uncover an area the presenter is uncomfortable speaking on. You should be familiar with the details, e.g., project statuses, but I think that it’s usually best to reframe the discussion when you get too far into the details. Try to pop up to either the data or the principles, which tend to be more useful conversations. (Location 1406)
Prepare a lot; practice a little. If you’re presenting to your entire company, practicing your presentation is time well spent. Leadership presentations tend to quickly detour, so practice isn’t quite as useful. Practice until you’re comfortable, but prefer to prepare instead getting deeper into the data, details, and principles. As a corollary, if you’re knowledgeable in the area you’re responsible for, and have spent time getting comfortable with the format, over time you’ll find that you won’t need to prepare much for these specifically. Rather, whether you’re able to present effectively without much preparation will become a signal for whether you’re keeping up with your span of responsibility. (Location 1409)
Make a clear ask. If you don’t go into a meeting with leadership with a clear goal, your meeting will either go nowhere or go poorly. Start the meeting by explicitly framing your goal! (Location 1415)
Figure 3.8 The expected and actual experience of presenting to executives. (Location 1418)
My general approach to presenting to senior leaders is: Tie topic to business value. One or two sentences to answer the question “Why should anyone care?” Establish historical narrative. Two to four sentences to help folks understand how things are going, how we got here, and what the next planned step is. Explicit ask. What are you looking for from the audience? One or two sentences. Data- driven diagnosis. Along the lines of a strategy’s diagnosis phase, 39 explain the current constraints and context, primarily through data. (Location 1420)
Decision- making principles. Explain the principles that you’re applying against the diagnosis, articulating the mental model you are using to make decisions. What’s next and when it’ll be done. Apply your principles to the diagnosis to generate the next steps. It should be clear to folks reading along how your actions derive from your principles and the data. If it’s not, then either rework your principles or your actions! Return to explicit ask. The final step is to return to your explicit ask and ensure that you get the information or guidance you need. (Location 1429)
When you sit down for coffee with a manager, you can probably guess the biggest challenge on their mind: time management. Sure, time management isn’t always everyone’s biggest challenge, but once the crises of the day recede, it comes to the fore. (Location 1439)
Quarterly time retrospective. Every quarter, I spend a few hours categorizing my calendar from the past three months to figure out how I’ve invested my time. This is useful for me to reflect on the major projects I’ve done, and also to get a sense of my general allocation of time. I then use this analysis to shuffle my goal time allocation for the next quarter. (Location 1447)
Prioritize long- term success over short- term quality. As your scope increases, the important work that you’re responsible for may simply not be possible to finish. Worse, the work that you believe is most important, perhaps high- quality one- on- ones, is often competing with work that’s essential to long- term success, like hiring for a critical role. Ultimately, you have to prioritize long- term success, even if it’s personally unrewarding to do so in the short term. It’s not that I like this approach, it’s that nothing else works. (Location 1451)
Finish small, leveraged things. If you’re doing leveraged work, 40 then each thing that you finish41 should create more bandwidth to do more future work. It’s also very rewarding to finish things. Together, these factors allow large volumes of quick things to build into crescendoing momentum. (Location 1455)
Stop doing things. When you’re quite underwater, a surprisingly underutilized technique is to stop doing things. If you drop things in an unstructured way, this goes very poorly, but done with structure this works every time. Identify some critical work that you won’t do, recategorize that newly unstaffed work as organizational risk, 42 and then alert your team and management chain that you won’t be doing it. This last bit is essential: it’s fine to drop things, but it’s quite bad to silently drop them. (Location 1459)
Size backward, not forward. A good example of this is scheduling skip- levels. 43 When you start managing a multi- tier team, say 20 individuals, you can specify a frequency for skip- levels and reason forward to figure out how many hours of skip- levels you’ll do in a given week. Say you have 16 indirect reports, and you want to see them once a month for 30 minutes, so you end up doing two hours per week. (Location 1464)
Delegate working “in the system.” Wherever you’re working “in the system,” 44 design a path that will enable someone else to take on that work. It might be that this plan will take a year to come together, and that’s fine, but what’s not all right is if it’s going to take a year and you haven’t even started. (Location 1471)
Trust the system you build. Once you’ve built the system, at some point you have to learn to trust it. The most important case of this is handing off the responsibility to handle exceptions. Many managers hold onto the authority to handle exceptions for too long, and at that point you lose much of the system’s leverage. Handling exceptions can easily consume all of your energy, and either delegating them or designing them out of the system is essential to scaling your time. (Location 1474)
Decouple participation from productivity. As you grow more senior, you’ll be invited to more meetings, and many of those meetings will come with significant status. Attending those meetings can make you feel powerful, but you have to keep perspective about whether you’re accomplishing much by attending. Sometimes, being able to convey important context to your team is super valuable, and in those cases you should keep attending, but don’t fall into the trap of assuming that attendance is valuable. (Location 1478)
Hire until you are slightly ahead of growth. The best gift of time management that you can give yourself is hiring capable folks, and hiring them before you get overwhelmed. By having a clear organizational design, you can hire folks into roles before their absence becomes crippling. (Location 1481)
Calendar blocking. Creating blocks of time on your calendar is the perennial trick of time management: add three or four two- hour blocks scattered across your week to support more focused work. It’s not especially effective, but it does work to some extent and is quick to set up, which has made me a devoted user. (Location 1484)
Getting administrative support. Once you’ve exhausted all the above tools and approaches, the final thing to consider is getting administrative support. I was once quite skeptical of whether admin support is necessary— and, until your organization and commitments reach a certain level of complexity, it isn’t— but at some point having someone else handling the dozens of little interruptions is a remarkable improvement. (Location 1487)
building a community of learning with your peers. This works especially well in a gelled “first team,” 45 and, recently I’ve been spending more time facilitating a broader learning community of engineering managers. (Location 1500)
When I first started facilitating the group, we focused on content- rich presentations. Each slide was dense with important lessons and essential details. It didn’t work well. Folks weren’t engaged. Attendance dropped. Learning was not the order of the day. (Location 1503)
Be a facilitator, not a lecturer. Folks want to learn from each other more than they want to learn from a single presenter. Step back and facilitate. (Location 1506)
Brief presentations, long discussions. Present a few minutes of content, maybe five, and then move into discussion. Keep the discussions short enough that even if a group doesn’t get traction on a given topic, it doesn’t become awkward. A good time limit would be 10 minutes. (Location 1508)
Small breakout groups. Giving folks time to discuss in small groups allows them to learn a bit about the topic in a small, safe place. It also gives everyone an opportunity to be part of the discussion, which is a lot more engaging than listening to others for an hour. (Location 1510)
Bring learnings to the full group. After discussions, give each group an opportunity to bring their discussion back to the larger group, to allow the groups to cross- pollinate their learnings. (Location 1513)
Choose topics that people already know about. Successful topics are ones that people have already thought about, typically because these concepts are core to their daily work. Ideally the topic is something that they do but would like to get better at, such as one- on- ones, mentorship, coaching, or career development. (Location 1515)
Encourage tenured folks to attend. For many learning communities, you’ll find that the most senior or most tenured folks opt out to focus on other work. This is a shame, because there is so much for them to teach newer folks, and also because it creates an opportunity for them to learn from and get to know new members. (Location 1520)
Optional pre- reads. Some folks aren’t comfortable being introduced to a new topic in public, and for those individuals, providing a list of optional pre- reads can help them prepare for the discussion. I find that most people don’t read them (which, surprisingly, I also found true when hosting paper- reading groups46), but for some folks they’re very helpful. (Location 1522)
Checking in. Depending on the size of the group, it can be powerful to start by checking in with each other, having each person give a 20- or 30- second self- introduction. The format we’ve been using lately is your name, your team, and one sentence about what’s on your mind. This is especially useful in quickly growing communities, as it makes it easier for individuals to meet each other. (Location 1526)
The thing I enjoy most about this format is that it gives folks what they really want, spending time learning from each other, and is remarkably quick for the facilitator to prepare. I’m far from a seasoned facilitator, and I’ve also found this format to be a rewarding and safe opportunity for me to grow as a facilitator. (Location 1529)
worked with a coworker whose philosophy was “If you don’t ask for it, you’ll never get it.” Which culminated in continuous escalations to management for exceptional treatment. This approach was pretty far from my intuition of how a well- run organization should work, and it grated on my belief that consistency is a precondition of fairness. (Location 1546)
environments that tolerate frequent exceptions are not only susceptible to bias but are also inefficient. (Location 1549)
organizations survive by adapting to the dynamic circumstances they live in. An organization stubbornly insisting on its established routines is a company pacing a path whose grooves lead to failure. (Location 1551)
Every policy you write is a small strategy, 1 built by identifying your goals and the constraints that bring actions into alignment with those goals. (Location 1556)
The fixed cost of creating and maintaining a policy is high enough that I generally don’t recommend writing policies that do little to constrain behavior. In fact, that’s a useful definition of bad policy. In such cases, I instead recommend writing norms, which provide nonbinding recommendations. Because they’re nonbinding, they don’t require escalations to address ambiguities or edge cases. (Location 1576)
Once you’ve supported your goals through constraints, all you have to do is consistently uphold your constraints. This is easy to say, but consistency requires no little bravery. Even with the best intentions, I’ve often gone astray when it was time for me to support my own policies. (Location 1579)
Accepting reduced opportunity space. Good constraints make trade- offs that deliberately narrow your opportunity space. Some of the opportunities that you’ll encounter within that space will be exceptionally good, and it’s hard to stay true when faced with concrete consequences. (Location 1583)
Locally suboptimal. Satisfying global constraints inevitably leads to local inefficiency, sometimes forcing some teams to deal with deeply challenging circumstances in order to support a broader goal that they may experience little benefit from. (Location 1585)
When we’ve picked thoughtful constraints to allow us to accomplish important goals, we need the courage to bypass these opportunities and accept these local inefficiencies. If we don’t summon and maintain that courage, we incur most of the costs and receive few of the benefits. (Location 1589)
Granting exceptions undermines people’s sense of fairness, and sets a precedent that undermines future policy. In environments where exceptions become normalized, leaders often find that issuing writs of exception— for policies they themselves have designed— starts to swallow up much of their time. Organizations spending significant time on exceptions are experiencing exception debt. The escape is to stop working the exceptions, and instead work the policy. (Location 1592)
Once you’ve invested so much time into drafting policy, you have to avoid undermining your work, and yourself, with exceptions. That said, you can’t simply ignore escalations and exceptions requests, which often represent incompatibilities between the reality you designed your policy for and the reality you’re operating in. Instead, collect every escalation as a test case for reconsidering your constraints. (Location 1596)
Once you’ve collected enough escalations, revisit the constraints that you developed in the original policy, merge in the challenges discovered in applying the policy, and either reaffirm the existing constraints or generate a new series of constraints that handle the escalations more effectively. (Location 1599)
This approach is powerful because it creates a release valve for folks who are frustrated with rough edges in your current policies— they’re still welcome to escalate— while also ensuring that everyone is operating in a consistent, fair environment; escalations will only be used as inputs for updated policy, not handled in a one- off fashion. (Location 1602)
When you roll out a policy, it’s quite helpful to declare a future time when you’ll refresh it, which ensures that you’ll have the time to fully evaluate your new policy before attempting revision. (Location 1605)
The next time you’re about to dive into fixing a complicated one- off situation, consider taking a step back and documenting the problem but not trying to solve it. Commit to refreshing the policy in a month, and batch all exceptions requests until then. (Location 1609)
Folks who communicate a no effectively are not the firmest speakers, nor do they make frequent use of the word itself. They are able to convincingly explain their team’s constraints and articulate why the proposed path is either unattainable or undesirable. (Location 1625)
Articulating your constraints depends on the particulars of the issue at hand, but I find that two topics are frequent venues of disagreement. The first is velocity: Why is this taking so long when it should take a couple of hours? The other is prioritization: Why can’t you work on this other, more important, project? (Location 1627)
When folks want you to commit to more work than you believe you can deliver, your goal is to provide a compelling explanation of how your team finishes work. Finishes is particularly important, as opposed to does, because partial work has no value, and your team’s defining constraints are often in the finishing stages. (Location 1632)
The most effective approach that I’ve found for explaining your team’s delivery process is to build a kanban board2 describing the steps that work goes through, and documenting who performs which steps. (Location 1634)
You want to focus your team on your core constraint, the single inefficient component that’s slowing down your throughput of finished work. Once you’ve focused the conversation on your core constraint, the next step is explaining what’s preventing you from solving for it. (Location 1641)
Once you’re able to explain your constraints and how time is being spent, then you’re having a useful conversation about whether you can shift time from other behaviors toward your constraints. The final stage comes next, which is the discussion around adding capacity. (Location 1648)
the best outcome of a discussion on velocity is to identify a reality- based approach that will support your core constraint. The second- best outcome is for folks to agree that you’re properly allocated against your constraints and to shift the conversation to prioritization. (Those are the only good outcomes.) (Location 1655)
Although shifting from a discussion about velocity to one about prioritization is a good outcome, expressing your priorities convincingly can be a difficult, daunting task. I recommend breaking it down into three discrete steps: document all your incoming asks, develop guiding principles for how work is selected, and then share subsets of tasks you’ve selected based on those guiding principles. (Location 1658)
What I’ve found effective is to blend existing planning artifacts (typically quarterly/ annual plans) and your tickets into a list, and then test it against your most important stakeholders. (Location 1662)
you have to pick the guiding principles that you’ll use for selecting tasks. (Location 1664)
The last step is sitting down with your team and applying your guiding principles to the universe of incoming asks, then finding the subset to prioritize. (Location 1670)
Which, it so happens, is exactly what you should do when a stakeholder disagrees with your priorities. Understand their requests, and sit down with them to test their ask against your guiding principles and your currently prioritized work. If their request is more important than your current work, shift priorities at your next planning session. (To limit churn created by shifting priorities, it’s useful to wait for the next planning session instead of making these changes immediately. (Location 1672)
If you’ve poured time into explaining both your velocity and priorities but your perspective still isn’t resonating, then it’s fairly likely that you have a relationship problem to address. (Location 1677)
When I started managing, my leadership philosophy was simple: The Golden Rule6 makes a lot of sense. Give everyone an explicit area of ownership that they are responsible for. Reward and status should derive from finishing high- quality work. Lead from the front, and never ask anyone to do something you wouldn’t. (Location 1684)
believe that management, at its core, is an ethical profession. To see ourselves, we don’t look at the mirror, but rather at how we treat a member of the team who is not succeeding. Not at the mirror, but at our compensation philosophy. Not at the mirror, but at how we pitch the roles to candidates. Whom we promote. How we assign raises. Provide growth opportunities. PTO requests. Working hours. (Location 1692)
We have such a huge impact on the people we work with— and especially on the people who work “for” us— and taking responsibility for that impact is fundamental to good management. (Location 1695)
I believe that almost every internal problem can be traced back to a missing or poor relationship, and that with great relationships it is possible to come together and solve almost anything. (Location 1700)
try to start debugging problems from the relationship angle, and I find this technique pretty effective. (Location 1706)
“With the right people, any process works, and with the wrong people, no process works.” (Location 1708)
Process is a tool to make it easy to collaborate, and the process that the team enjoys is usually the right process. If your process is failing somehow, it’s worth really digging into how it’s failing before you start looking for another process to replace it. (Location 1710)
In this profession, we’re often asked to deal with difficult situations. No set of rules can guide you safely through every scenario, but I have found that postponement is never the best solution. Instead of avoiding the hardest parts, double down on them. (Location 1715)
If you have a poor relationship with your manager or a member of your team, spend even more time with them. Meet with them every day, or have dinner with them. If two engineers are struggling to work together, before you separate them onto different teams get them to spend more time together trying to understand each other’s perspective. (Location 1718)
of a mantra for guiding decisionmaking: do the right thing for the company, the right thing for the team, and the right thing for yourself, in that order. (Location 1723)
make sure that your choices are being made on behalf of your team, not on your own behalf. (Location 1728)
Last in the list is yourself, but while I do believe that you should generally put yourself last, it’s also a reminder to “pay yourself.” Burnout is endemic in our industry, and a burned- out manager often leaks onto their team. Give as much as you can sustainably give, and draw the line there. (Location 1731)
You can’t fix everything at once, so you’ll often be doing something mediocre at any given point in time, but remember to come back and improve it when you can (e.g., pay down your management debt). (Location 1740)
the best management philosophy never stands still, but— in the model of the Hegelian dialectic8— continues to evolve as it comes in contact with reality. (Location 1742)
The most confusing places to start are midsize, rapidly growing companies. That’s because parts of the company are growing quickly, with an emphasis on execution, and other parts have largely stabilized, with ideas becoming the more valued currency. Long bones have growth plates at their ends, which is where the growth happens, and the middle doesn’t grow. (Location 1750)
At a small startup or in a rapidly growing company’s growth plates, you’re mostly dealing with new problems. (Location 1754)
You’d expect that novel ideas would be heavily valued in these circumstances, but, interestingly, it’s the opposite: execution is the primary currency in the growth plates. (Location 1757)
It’s common for well- meaning individuals from outside the growth plates to jump in to help by supplying more ideas, but that’s counterproductive. What folks in the growth plates need is help reducing and executing the existing backlog of ideas, not adding more ideas that must be evaluated. Teams in these scenarios are missing the concrete resources necessary to execute, and supplying those resources is the only way to help. Giving more ideas feels helpful, but isn’t. (Location 1760)
I think it’s important to recognize to recognize that, in the growth plates, you are focused on surviving to the next round, which might be a different growth challenge, or might be the team stabilizing. It is extremely hard to consistently do the basics well in these circumstances, because you simply won’t have enough time to do them well. You’ll have to get comfortable doing as well as time constraints allow, and sometimes that will lead to being mediocre at things you’re passionate about. (Location 1764)
Away from the growth plates, you are mostly working on problems with known solutions. Known solutions are amenable to iterative improvement, so it would make sense for execution to be highly valued, but I find that, in practice, ideas— especially ideas that are new within your company— are most highly prized. (Location 1770)
All slow- growth environments used to be high- growth environments, which means they were once run by someone who was a sufficiently effective executor to evolve them into a slow- growth environment. (Location 1772)
Consequently there tends to be less iterative improvement available than you’d expect. So often, we make solid executors responsible for slower- growth areas— we need the innovators in the highest- growth ones— but the opposite tends to work better. (Location 1774)
be thoughtful about carrying your values with you from one context into another. Leadership is matching appropriate action to your current context, and it’s pretty uncommon that any two situations will flourish from the same behaviors. (Location 1779)
Camille Fournier’s “How Do Individual Contributors Get Stuck?” (Location 1784)
Newer managers, often in their first couple of years: Only manage down. This often manifests in building something your team wants to build, but which the company and your customers aren’t interested in. Only manage up. In Pearl S. Buck’s The Good Earth, 11 she writes, “All power comes from the Earth.” In management, power comes from a healthy team. Some managers focus so much on following their management’s wishes that their team evaporates beneath them. Never manage up. Your team’s success and recognition depend significantly on your relationship with your management chain. It’s common for excellent work to go unnoticed because it was never shared upward. Optimize locally. Picking technologies that the company can’t support, or building a product that puts you in competition with another team. Assume that hiring never solves any problems. When you’re behind, it can be tempting to spend all of your time firefighting and neglect hiring, but if your business is growing quickly, then eventually you hire or burn out. Don’t spend time building relationships. Your team’s impact depends largely on doing something that other teams or customers want, and getting it shipped out the door. This is extraordinarily hard without a supportive social network within the company. Define their role too narrowly. Effective managers tend to become the glue in their team, filling any gaps. Sometimes that means doing things you don’t really want to do, in order to set a good example. Forget that their manager is a human being. It’s easy to get frustrated with your manager when they put you in bad situations, forget to tell you something important, or commit your team to something without consulting you, but they almost certainly did it with the best of intentions. To have a good relationship with your manager, you have to give them room to make mistakes. (Location 1789)
More experienced managers: Do what worked at their previous company. When you start a new job or new role, it’s important to pause to listen and foster awareness before you start “fixing” everything. Otherwise, you’re fixing problems that may not exist, and doing so with tools that may not be appropriate. Spend too much time building relationships. This is particularly common in managers coming from larger companies into smaller ones, and it creates the perception that the manager isn’t contributing anything of value. This tends to be because smaller companies expect more execution focus than relationship management focus from their managers. Assume that more hiring can solve every problem. Adding a few wonderful people to the team can solve many problems, but adding too many people can dilute your culture, and lead to people with unclear roles and responsibilities. Abscond rather than delegate. Delegation is important, but it’s easy to go too far and ignore the critical responsibilities that you’ve asked others to take on, only to discover an easily averted disaster later on. Become disconnected from ground truth. Particularly at larger companies, it can become frequent to make decisions that appear to be fundamentally disconnected from reality. (Location 1809)
Managers of any and all levels of experience: Mistake team size for impact. Managing a larger team is not a better job, it’s a different job. It also won’t make you important or make you happier. It’s hard to unlearn a fixation on team size, but if you can, it’ll change your career for the better. Mistake title for impact. Titles are arbitrary social constructs that only make sense in the context they’re given. Titles don’t translate across companies meaningfully, and they’re a deeply flawed way to judge yourself or others. Don’t let them become your goal. Confuse authority with truth. Authority lets you get away with weak arguments and poor justifications, but it’s a pretty expensive way to work with people, because they’ll eventually turn off their minds and simply follow orders— if they’re in a complicated compensation or life situation, that is. Otherwise, they’ll just leave. Don’t trust the team enough to delegate. You can’t scale your impact or engage your team if you don’t give them enough room to do things differently than you would. Many organizations become bottlenecked on approvals, which is a sure proxy for lack of trust. Let other people manage their time. Most managers have significantly more work they could be doing than they’re able to do. This will probably be your status quo for the rest of your career, and it’s important to prioritize your time on important things, and not simply on whatever happens to end up on your calendar. Only see the problems. It can be easy to only see what’s going wrong, and forget to celebrate the good stuff. Down this path lie frustration and madness. (Location 1821)
To partner successfully with your manager: You need them to know a few things about you. You need to know a few things about them. You should occasionally update the things you know about each other. (Location 1845)
Things your manager should know about you: What problems you’re trying solve. How you’re trying to solve each of them. That you’re making progress. (Specifically, that you’re not stuck.) What you prefer to work on. (So that they can staff you properly.) How busy you are. (So that they know if you can take on an opportunity that comes up.) What your professional goals and growth areas are. Where you are between bored and challenged. How you believe you’re being measured. (A rubric, company values, some KPIs, etc.) (Location 1848)
Some managers are easier to keep informed than others, and success hinges on finding the communication mechanism that works for them. The approach that I’ve found works well is: Maintain a document with this information, which you keep updated and share with your manager. For some managers, this will be enough! Mission accomplished. Sprinkle this information into your one- on- ones, focusing on information gaps (you’re not seeing support around a growth area, you’re too busy, or not busy enough, and so on). Success is filling in information gaps, not reciting a mantra. At some regular point, maybe quarterly, write up a self- reflection that covers each of those aspects. (I’ve been experimenting with a “career narrative” format that is essentially a stack of quarterly self- reflections.) Share that with your manager, and maybe with your peers too! (Location 1853)
knowing some things about your manager and their needs. Here are some good things to know: What are their current priorities? Particularly, what are their problems and key initiatives. When I get asked this question, I often can’t answer it directly, because what I’m focused on is people- related, but it’s a warning sign if your manager never answers it (either because because they don’t know, or they are always working on people issues). How stressed are they? How busy are they? Do they feel like they have time to grow in their role or are they grinding? Is there anything you can do to help? This is particularly valuable for managers who don’t have strong delegation instincts. What is their management’s priority for them? What are they trying to improve on themselves, and what are their goals? This is particularly valuable to know if they appear stuck, 12 because you may be able to help unstick them. (You could be especially helpful by redefining impact in terms of work that your team can accomplish versus growing team size, which is a frequent source of stickiness!) (Location 1862)
there are three types of engineering management jobs: Manager: you manage a team directly, Director: you manage a team of managers, VP: you manage an organization. (Location 1882)
Especially early in your management career, it’s easy to conflate reaching the next “rung” with reaching a certain number of people you’ve managed. Following this line of reasoning, for a 100- person company to hire you, you might need five direct reports to be a manager, 20 to be a director, and 40 to be a VP. (Location 1886)
As managers looking to grow ourselves, we should really be pursuing scope: not enumerating people but taking responsibility for the success of increasingly important and complex facets of the organization and company. This is where advancing your career can veer away from a zero- sum competition to have the largest team and evolve into a virtuous cycle of empowering the organization and taking on more responsibility. (Location 1891)
Companies will always need someone to run their cost- accounting initiatives, to set up their approach to on- call, to iterate on their engineer- recruiting process. Strong execution in these crosscutting projects will give you the same personal and career growth as managing a larger team. Project- managing an initiative working with 50 engineering managers is a far better learning opportunity than managing an organization of 50, and it builds the same skills. (Location 1895)
you can always find an opportunity to increase your scope and learning, even in a company that doesn’t have room for more directors or vice presidents. (Location 1899)
If you’ve been focused on growing the size of your team as the gateway to career growth, call bullshit on all that, 13 and look for a gap in your organization or company that you can try to fill. You’ll be a lot happier. (Location 1903)
It took me two years as a manager to reach the “leadership is lonely” phase. Folks had warned me that it would happen, and it did. (Location 1907)
For much of your early career, you’ll have folks who are routinely giving feedback on your work. As your span of responsibility grows, particularly if it’s somewhat specialized, increasingly no one will feel responsible for or able to provide that feedback. (Location 1915)
As a functional leader, you’ll be expected to set your own direction with little direction from others. When things in your area are going poorly, you’ll be swamped with more direction and input than you can readily absorb, but when things are going well, you’ll often be responsible for supplying your own direction and that of your team. (Location 1920)
If you don’t supply it yourself, you’ll start to feel the pull of irrelevance: Maybe no one really cares what we do? What would happen if I stopped showing up? Maybe I should be doing something different? (Location 1923)
That initial instinct to leave after hitting a pocket of seeming irrelevance is a comforting one, but it’s the wrong way to go. You can certainly avoid the current swells of ambivalence by switching jobs, but if you’re successful at another company then you’ll end up in the same situation. (Location 1925)
This is a symptom of success. You have to learn the lesson it’s trying to teach you: How to set your organization’s direction and your own. (Location 1927)
The first step to setting direction is to cast the widest possible net for ideas. (Location 1929)
This first phase is discovery without judgement. You should take ideas from everywhere and generate a pile of ideas that folks are pursuing, even if you think they’re terrible. (Location 1933)
Once your pile of ideas has gotten large enough, craft it into a strategy, 15 and then start testing that strategy. Keep refining and exploring your strategy until you can figure out what the key decisions are, a kind of ad hoc sensitivity analysis. 16 Once you identify the key pivots in your strategy, you’re finally prepared to define a direction! (Location 1935)
Make a clear decision on each of those pivots, write up a document explaining those decisions, and then see if you can get anyone to read it. They’ll disagree with a lot of what you’ve written, or else they’ll be confused by it. Keep testing, and refine the confusion down to the smallest group of controversial problems possible. (Location 1939)
Once you have those problems, return to your rounds of engaging with experienced leaders at other companies, and ask them how they’ve made those trade- offs before. Ask them for their stories. Ask them for the context that made one path perfect early on, and why they changed their minds as their company grew larger. (Location 1941)
The one remaining problem is that almost no one will have the time to soak up the full detail of your overly precise document, so the final step is to distill it into something comprehensible without hours of close reading. I’m still working on the best way to do this, but I suspect that it’s cutting all unnecessary, and even most essential, complexity in order to capture as much of the meaning as possible in three to four bullet points. (Location 1945)
I think that this resonates with everyone’s transition to managing managers: it’s an unsettling period when you lose access to what used to make you happy— partnering directly with a team— and haven’t found new sources of self- worth in your work. (Location 1951)
This isn’t the only reason this transition is hard, it’s also hard because a lot of your skills and habits stop working well. The skill that scales the worst is outworking your problems. (Location 1953)
This is particularly frustrating, because your ability to put your head down and solve gritty, important problems was probably a big part of how you were promoted. Now it’s the wrong answer to most of your problems. This isn’t because it’s bad behavior, just because it’s too inefficient to accomplish the breadth and quantity of things you need to get done. (Location 1955)
For every problem that comes your way— an email asking for a decision, a production problem, a dispute around on- call, a request to transfer from one team to another— you must pick one of three options: (Location 1960)
Close out. Close it out in a way such that this specific ask is entirely resolved. This means making a decision and communicating it to all involved participants. This strategy is a success if this particular task never comes back to you; and your goal is to finish this particular task as quickly and as permanently as possible. (Location 1961)
Solve. Design a solution such that you won’t need to spend time on this particular kind of ask again in the next six months. This is often designing norms or process, but depending on the kind of issue, this might be coaching an individual. With this option, your goal is to finish off an entire category of tasks. (Location 1964)
Delegate. Ideally, this is to redirect the ask to someone who is responsible for that kind of work, but sometimes it is a one- off. If you can’t close out a task or solve it, your only other option is to delegate it to someone who either has the specialized skills to close/ solve it, or who can work in the system. (Location 1967)
an inclusive organization is one in which individuals have access to opportunity and membership. Opportunity is having access to professional success and development. Membership is participating as a version of themselves that they feel comfortable with. (Location 1986)
There are workplaces where everyone around you is delightful, the customers are friendly, and you feel respected, but you still return home each night dissatisfied. Occasionally an interesting project will come up, but those typically go to more tenured folks. When I think about having access to opportunity, I think about ensuring that folks can go home most days feeling fulfilled by challenge and growth. (Location 1991)
The most effective way to provide opportunity to the members of your organization is through the structured application of good process. Good process is as lightweight as possible, while being rigorous enough to consistently work. (Location 1994)
Structure application allows folks to learn how the processes work, and lets them build trust by watching the consistent, repeated application of those processes. (Location 1995)
The key question is whether you’ll continue to respect your processes when it’s inconvenient to do so. If one of your best team members wants a specific opportunity, are you willing to run an open application process? What if they plan to leave your company otherwise? Would you be willing to bypass your processes to keep them? (Location 1997)
There are infinite ways to create and distribute opportunity! Some of the programs that I have found more helpful are: Rubrics everywhere. Every important people decision should have a rubric around how folks are evaluated. This is true for promotions, performance designations, hiring, transitions into management, and pretty much everything else! Selecting project leaders. 1 Having a structured approach to selecting project leads allows you to learn from previous selections, and to ensure that you’re not concentrating opportunity on a small set of individuals. Explicit budgets. Many companies take a “spend it like your own money” approach to budgets, which often leads to large inconsistencies across individuals. Instead of saying that you’ll pay for teams to attend a reasonable number of conferences per year, specify a fixed number. Instead of maintaining a general ongoing education budget, make it explicit. Nudge involvement. Many people are uncomfortable applying to opportunities, using education budgets, asking for mentorship, etc. It’s very effective to reach out to those folks directly and recommend they apply. Even more powerful is showing them where they fall on a distribution: it’s one thing to know that you’ve never used your education budget, and something else entirely to know that you’re the only person who isn’t using it. Education programs. Create ongoing training and learning programs that are available for everyone, or, for example, for all managers. (Location 2000)
The metrics that have been useful for me: Retention is the most important measure of availability of opportunity, although it’s also a very lagging indicator. This should be the first thing you’re paying attention to, but you must recognize that it’s slow to show change. Usage rate is how often folks get picked in project selection. 2 The number of distinct team members picked to lead critical projects is a particularly interesting measure. Level distribution is useful, in particular comparing cohorts of folks with different backgrounds. People want role models for themselves in senior roles at the company where they work, which is why looking at the representation of underrepresented minorities and women is only a start. You also want to look in each role and level of seniority. Time at level is how long team members wait between promotions. How does this compare across cohorts? Something to watch for is that this number is also greatly influenced by initial level at hiring. For example, time at level might look equivalent because some cohorts are being under- leveled at time of hire. (Location 2017)
If you’re spending so much energy wondering whom you’ll eat lunch with, that’s energy you can’t spend being creative. If the idea of going to work gives you anxiety, at some point you’re going to decide to stop coming. Membership is the precondition to belonging. (Location 2033)
The programs I’ve found most impactful here: Recurring weekly events allow coworkers to interact socially. These are held during working hours, are open to folks from many different teams to attend, and are optional. One of my personal favorites is hosting a paper- reading group. 3 Employee Resource Groups (ERGs) create opportunities for folks with similar backgrounds to build community. Team offsites once a quarter or so are a good chance to pause, reflect, and work together differently. Spending a day together learning and discussing is surprisingly effective at making individuals feel like a team. This is particularly true for groups of managers, whose daily cadence is typically more in tune with their teams than with their peers. Coffee chats, perhaps randomly assigned by Donut, 4 get folks from different teams interacting when they don’t need something from each other. Team lunches give folks time to relax a bit and interact socially. Held once a week or so, they can become a pleasant ritual. These can be a bit risky, at least for folks (like early hires) who feel uncomfortable in their team. Navigating the social mores of an entire team can be much more difficult than in a one- on- one. (Location 2035)
I’ve found membership rather harder to measure than opportunity. Here are some of the potential measures: Retention is once again the golden measure, and once again a long- trailing indicator. Referral rate by cohort provides insight into which individuals feel comfortable asking their friends and previous coworkers to join the company. Attendance rates for recurring events and team lunches provide some insight into whether folks feel comfortable with those groups. The quantity and completion rate of coffee chats are automatically measured with Donut. (Location 2051)
Many activities and events don’t work well for everyone— meals can be difficult for individuals with complex dietary restrictions, physical activities make some uncomfortable, activities after working hours can exclude parents— and success here requires both a broad portfolio of options and a willingness to balance concerns across events and time. (Location 2060)
Combine efforts on opportunity and membership, and you will find yourself solidly on the path to an inclusive organization. This strategy doesn’t have much flash, but results are louder than proclamations. (Location 2063)
Have you ever worked at a company where the same two people always got the most important projects? Me too. It’s frustrating to watch these opportunities to learn from the sidelines, and reliance on a small group can easily limit a company’s throughput as it grows. This is so important that I’ve come to believe that having a wide cohort of coworkers who lead critical projects is one of the most important signifiers of good organizational health. (Location 2068)
it simultaneously measures the company’s capability to execute projects and the extent that its members have access to growth. The former measurement helps determine the company’s potential throughput, and the latter correlates heavily with inclusivity. (Location 2071)
there are two kinds of projects: critical projects and everything else. Critical projects are scarce. There are more people who want them than can get access to them. Other projects are abundant. You might not be able to get one immediately, but if you wait a month or two the odds are good. There’s no need to be structured about abundant projects! (Location 2073)
Define the project’s scope and goals in a short document. Particularly important are identifying: Time commitment. People need to decide if they must ask permission from their managers. Requirements to apply. If there are no requirements, say so explicitly; otherwise, a lot of folks will assume that there are, and will opt out. Selection criteria. If multiple individuals apply, how will you select the project leader between them? Announce the project to a public email list, at an all- hands, over Slack, or however your company does persistent communication; I tend to use email for these. What’s most important is that you: Allow folks to apply in private. Some individuals will be uncomfortable applying in public. Make sure that applicants don’t see who else has applied. Some people will see someone they view as senior apply, and will immediately disengage because they feel that they are less qualified. Give at least three working days for people to apply. Do this whenever possible, as some folks will need to talk with their manager or peers to muster up the confidence to apply. Nudge folks to apply who you think would be good candidates but who might not self- select. This is particularly important for getting new people into the process. Select a project leader based on the selection criteria you specified. Take the time to consider every single applicant against the criteria, and, if possible write up a paragraph or two about each of them. Once you’ve selected the leader, privately reach out to them to confirm that they’re able to commit. Sponsor the project leader by finding someone who has successfully completed a similar project to be their advisor. This sponsor will be accountable for coaching the leader to successful completion. This is a great learning opportunity for sponsors, as they are typically folks who are great at doing things themselves, but not as used to teaching others how to lead large and ambiguous projects. Notify other individuals who applied that they were not selected. It’s extremely helpful if you provide them feedback on why you didn’t select them. Sometimes it’s because they’ve already done something great and you want to create room for another person to learn, and that’s a totally reasonable thing to tell them! Kick off the project, notifying the same folks who received the application announcement who the project leader is, who the sponsor is, and what their plan for running the project is. Record the project, who was selected, and who the sponsor is into a public spreadsheet. Also link out to a project brief! (Location 2078)
While companies are literally composed of teams, 5 I’ve found it surprisingly common to meet folks who feel as if they are not a member of any team. Managers working directly with engineers tend to feel some membership in that team, but even the rarest occasions of authority create a certain distance. Managing managers lets you pierce the veil a bit more, but the curtain falls when it comes to performance management or assigning resources. (Location 2108)
As your span of responsibility grows, you may not know much of your peers’ work, or you may find yourself frequently contesting against them for constrained resources. Even when surrounded by the fastest of growth, you may be awkwardly aware that you’re aspiring to move into the same, rare, roles. (Location 2113)
These dynamics can lead to teams whose camaraderie is at best a qualified non- aggression pact, and in which collaboration is infrequent. It’s a strange tragedy that we hold ourselves accountable for building healthy, functional teams, and yet are so rarely on them ourselves. But it can be better. It’s okay to expect more. (Location 2115)
I’ve worked on a few teams in which folks consistently looked out for each other, and believed they’d all come out better together. These were teams that had individuals willing to disappoint the teams they managed in order to help their peers succeed. It wasn’t that these folks were ready to callously disappoint people. Rather, they balanced outcomes from a broad perspective that included their peers. (Location 2118)
The members of such a team have shifted their first team from the folks they support to their peers. While these teams are rare, I’ve come to believe that supporting their creation is simple— albeit hard— work, and when the conditions are fostered, they lead to an exceptionally rewarding work environment. (Location 2121)
Awareness of each other’s work. Even with the best intentions, a member cannot optimize for their team if they’re not familiar with other members’ work. The first step to moving someone’s identity to their peers is to ensure that they know about their peers’ work. This will require a significant investment of time, likely in the form of sharing weekly progress, and the occasional opportunity for folks to dive deep into each other’s work. (Location 2124)
Evolution from character to person. When we don’t know someone well, we tend to project intentions onto them, casting them as a character in a play they themselves are unaware exists. It’s quite challenging to optimize on behalf of characters in your mental play, but it’s much easier to be understanding of people you know personally. Spending time together learning about each other, often at a team offsite, will slowly transform strangers into people. (Location 2128)
Refereeing defection. In game theory, there is an interesting concept of a dominant strategy. A dominant strategy is one that is expected to return the maximum value regardless of the actions of other players. Team collaboration is not a dominant strategy. Rather, it depends on everyone participating together in good faith. If you see someone acting against the interests of the team, you, too, will likely defect to pursue your own self- interest. Some teams are tightly knit enough that no one ever attempts defection, but most teams experience frequent changes in membership and external conditions. I believe that on such teams coordination is only possible when the manager or a highly respected member operates as a referee, holding team members accountable for good behavior. (Location 2132)
Avoiding zero- sum culture. Some companies foster zero- sum cultures, in which perceived success depends on capturing scarce, metered resources, like head count. It’s hard to convince folks to coordinate under such conditions. Positive cultures center on recognizing impact, support, and development, which are all avenues that support widespread success. (Location 2138)
Making it explicit. If you have the first four ingredients, you still have to explicitly discuss the idea of shifting folks’ identities away from the team they support and toward the team of their peers. It’s hard to move membership from the team you spend the most time with, and I haven’t seen it happen organically. Given how much energy it takes to shift the identities of a team of managers away from the folks they support and toward their peers, I think it’s quite reasonable to question whether it’s genuinely worth doing it. You’ll be unsurprised to know that I think it is. (Location 2140)
As you move into larger roles, you’ll need to start considering challenges from the perspectives of more teams and people. In this sense, treating your peers as your first team allows you to begin practicing your manager’s job, without having to get promoted into the role first. The more fully you embrace optimizing for your collective peers, the closer your priorities will mirror your manager’s. Beyond practicing working from this broader lens, it will also position you for particularly useful feedback from your manager, as you’ll both be considering similar problems with shared goals. (Location 2145)
The best learning doesn’t always come directly from your manager, and one of the most important things a first team does is provide a community of learning. Your peers can only provide excellent feedback if they’re aware of your work and are thinking about your work similarly to how you are. Likewise, as you’re thinking about your peers’ work, you’ll be able to learn from how they approach it differently than you anticipate. Soon, your team’s rate of learning will be the sum of everyone’s challenges, no longer restricted to just your own experiences. (Location 2150)
Long term, I believe that your career will be largely defined by getting lucky and the rate at which you learn. I have no advice about luck, but to speed up learning I have two suggestions: join a rapidly expanding company, and make your peers your first team. (Location 2154)
Manager- of- managers searches are interesting in at least four ways: There are many folks who can’t find upward mobility within their current company. They have not managed managers before, and are looking for the opportunity. Most people with experience managing managers are happy in their current roles. The individuals interested in these roles outpace supply. This makes it more important to put in place processes like the Rooney Rule. 7 You need a fair way to consider candidates within your company. It must be respectful to them yet allow you to uphold your responsibilities to the company. (Location 2161)
Ensuring that internal candidates take part is essential to an inclusive culture. Fair consideration doesn’t mean that we prefer internal candidates. Rather, it means that there is a structured way for them to apply, and for us to consider them. Letting individuals apply is the easy part. You must announce each position and ask for internal candidates. You should persuade eligible candidates to apply, especially if they are uncertain. You should give them a week or two to consider whether they want to apply. (Location 2168)
Partnership. Have they been effective partners to their peers, and to the team that they’ve managed? Execution. Can they support the team in operational excellence? Vision. Can they present a compelling, energizing vision of the future state of their team and its scope? Strategy. Can they identify the necessary steps to transform the present into their vision? Spoken and written communication. Can they convey complicated topics in both written and verbal communication? Can they do all this while being engaging and tuning the level of detail to their audience? Stakeholder management. Can they make others, especially executives, feel heard? Can they make these stakeholders feel confident that they’ll address any concerns? (Location 2173)
This evaluation doesn’t cover every aspect of being an effective senior leader. But it does cover the raw skills that form the foundation of one’s success. You already know if an internal candidate has hired managers. You know if they’ve done organization design. (Location 2182)
Peer and team feedback. Collect written feedback from four or five coworkers. Include peers on other teams. Include people the applicants have managed. Include people they would not have managed. My biggest advice? Lean into controversial feedback, not away from it. Listen to would- be dissenters, and hear their concerns. A 90- day plan. The applicant writes a 90- day plan of how they’d transition into the role, and what they would focus on. They emphasize specific tactics, time management, and where they’d put their attention. This is also a great opportunity to understand their diagnosis of the current situation. Provide written feedback to them on their plan. Have them incorporate that feedback into their plan. This is an opportunity to try out working together in the new role. Vision/ strategy document. The applicant writes a combined vision/ strategy document. It outlines where the new team will be in two to three years, and how they’ll steer the team to get there. Provide written feedback on the document. Have them incorporate that feedback. Vision/ strategy presentation. Have the applicant present their vision/ strategy document to a group of three to four peers. Have the peers ask questions, and see how the applicant responds to this feedback. Executive presentation. Have the applicant present their strategy document, one- on- one, with an executive. In particular, test for their ability to adapt communication to different stakeholders. (Location 2185)
Know that internal processes are awkward. You’ll have many internal candidates. They will talk to each other. They will interview external candidates for a role they are applying for themselves. One candidate may end up managing the others. Don’t decide to avoid this morass of awkwardness. You can’t. You’re deferring it until later. It’ll still be awkward, but now awkwardly in the realm of gossip. (Location 2201)
Roger Miller (and later, much more famously, Janis Joplin) sang: “Freedom’s just another word for nothing left to lose.” 8 (Location 2207)
Positive freedom is your freedom to do: to vote, to wear the clothing you want, to own arms, to blow smoke into your neighbor’s porch when they’re trying to read a book outside on a sunny day. Negative freedom is your freedom from things: from being forced to take an impossible literacy exam before being allowed to vote, from to wear clothing you dislike or find oppressive, from having your cellular traffic recorded, from having your neighbors blow smoke onto your porch when you’re trying to read a book outside on a sunny day. (Location 2215)
“freedom” is neither inherently good nor inherently just, and descends into the murky gray that already embroils everything else in our lives. Each positive freedom we enforce strips away a negative freedom, and each negative freedom we guarantee eliminates a corresponding positive freedom. This sad state of affairs is often referred to as the Paradox of Positive Liberty. 11 (Location 2220)
I believe that the balancing of positive and negative freedoms is a fundamental task of managers and management. When we’ve lucked upon (or perhaps nurtured, if you’re much more talented than I) a phenomenal culture and a great team who are executing well along a worthy roadmap, then, like a central bank reducing interest rates to avoid a bubble, or like a jogger reducing their pace to lower their heart rate, we can carefully ramp toward negative freedom and away from positive freedom. This is one of our essential tools for facilitating and prolonging success. (Location 2223)
Using the two together, management slowly decelerates to keep the good times rolling, and accelerates to help push through challenging periods. (Location 2230)
Tom DeMarco’s Slack13 has an excellent suggestion for a good starting state between positive and negative freedoms for engineering teams: generally follow the standard operating procedure (i.e., keep doing what you’re already doing, the way you’re doing it), but always change exactly one thing for each new project. (Location 2235)
Ben Horowitz’s recent post on “Can Do vs. Can’t Do Cultures.” 14 I read that article as describing how young companies that are focused on innovation differ from mature companies that are trapped in “the innovator’s dilemma.” 15 Older companies can (and do) foster sheltered pockets of innovation, as in the example of Larry Page investing in good ideas that he encounters within Google, but maintaining a market position is fundamentally distinct from creating new markets. I think that the more complete argument is to use both cultures (and, in parallel, to place emphasis on positive and negative freedoms) in the appropriate circumstances. (Location 2240)
“work harder” mantra only breeds hero programmers whose heroic ways make it difficult for nonheroes to contribute meaningfully. (Location 2250)
as your new heroes finish martyring themselves on burnout, you’re left with three exceptionally challenging problems: You’ve bred a cadre of dissatisfied and burned- out heroes. You and your heroes have alienated everyone else. Your project is still totally screwed. (Location 2251)
Congratulations! You’re a hero programmer. You’re now working on five disparate projects, trying not to piss too many people off, but you’re having trouble getting everyone involved. It seems like they’re not really working as hard as you are, and it’s a bit of a drag, since you’re pulling 70- hour weeks and getting paged every Saturday night. (Location 2263)
When it comes to solving the problem of the hero programmer, your options are limited: either kill the environment that breeds hero programmers, or kill the hero programmer by burnout. (Location 2271)
One of the observations from systems thinking16 is that, though humans are prone to interpreting events as causal, often problems are better described in terms of a series of stockpiles that grow and shrink based on incoming and outgoing flows. (Location 2280)
Stocks and flows are especially valuable in understanding the failure of projects and teams. Projects fall behind one sprint at a time. Technical debt strangles projects over months. (Location 2284)
Your options for addressing a broken system depend on whether you’re in a position to set policy. If you set the original direction and have the leverage to change directions, then resetting is as simple as standing up and taking the bullet for the fiasco you’re embroiled in. (Location 2290)
Taking the blame is painful, and it only plays well with the crowds a couple of times. After that, people won’t trust you to lead them toward success, which makes some sense, since at that point you’ve led them off the rails multiple times. Fair’s fair. (Location 2292)
Without the leverage to change policy— and this doesn’t have to be direct authority, for influence is a powerful thing— you can’t start the healing, but you can help reach the reset point more quickly. (Location 2296)
Without policy, your tool is stepping back and allowing the brokenness to collapse under its own weight. A deeply flawed system can’t be saved by band- aids, but it can easily absorb your happiness to slightly extend its viability. If you step back, you conserve your energy and avoid creating rifts by pushing others away in hero mode, and you will be ready to be a part of a new— hopefully more functional— system after the reset does occur. (Location 2299)
Luck plays such an extraordinary role in each individual’s career progression that sometimes the entire concept of career planning seems dubious. However, as managers, we have an outsize influence in reducing the role of luck in the careers of others. That potential to influence calls us to hold ourselves accountable for creating fair and effective processes for interviewing, promoting, and growing the folks we work with. (Location 2313)
If long tenure holds a stigma, what of short tenure? Yep, that’s stigmatized, too. 2 Although, it’s certainly less stigmatized than it used to be. A fairly consistent belief across companies is that multiple stints below one year are a bad sign, but, generally as long as you’ve worked a few years somewhere, then having a career that is otherwise entirely composed of one- year stints raises few red flags. While (Location 2324)
Working at a company isn’t a single continuous experience. Rather it’s a mix of stable eras and periods of rapid change that bridge between eras. Thriving requires both finding a way to succeed in each new era and successfully navigating the transitional periods. You yourself trigger some transitions, like switching companies. Others happen on their own schedule: a treasured coworker leaves, your manager moves on, or the company runs out of funding. (Location 2333)
The good news is that both the stable eras and the transitions are great opportunities for growing yourself. Transitions are opportunities to raise the floor by building competency in new skills, and in stable periods you can raise the ceiling by developing mastery in the skills that the new era values. As the cycle repeats, your elevated floor will allow you to weather most transitions, and you’ll thrive in most eras by leveraging your expanding masteries. (Location 2346)
“If you’re offered a seat on a rocket ship, don’t ask what seat! Just get on.”—Sheryl Sandberg (Location 2353)
By tracking your eras and transitions, you can avoid lingering in any era beyond the point when you’re developing new masteries. This will allow you to continue your personal growth even if you’re working in what some would describe as a boring, mature company. The same advice applies if you’re within a quickly growing company or startup: don’t treat growth as a foregone conclusion. Growth only comes from change, and that is something you can influence. (Location 2356)
while interviewing well is far from easy, it is fairly simple. Be kind to the candidate. Ensure that all interviewers agree on the role’s requirements. Understand the signal your interview is checking for (and how to search that signal out). Come to your interview prepared to interview. Deliberately express interest in candidates. Create feedback loops for interviewers and the loop’s designer. Instrument and optimize as you would any conversion funnel. (Location 2372)
A good interview experience starts with being kind to your candidate. Being kind comes through in the interview process in a hundred different ways. When an interview runs overtime before you get to the candidate’s questions, the kind thing to do is to allow the candidate a few minutes to ask questions, instead of running on to the next interview to catch up. Likewise, in that scenario the kind thing is to then negotiate new staggered start times, rather than kicking off a cascade of poor interviewer time management as each person tries to fractionally catch up to the original schedule. (Location 2382)
My experience is that you can’t conduct a kind, candidate- centric interview process if your interviewers are tightly time- constrained. Conversely, if an interviewer is unkind to a candidate (and these unkindnesses are typically of the “with a whisper not a bang” variety), I believe it is very often a structural problem with your interviewing process, and not something you can reliably dismiss as an issue with that specific interviewer. (Location 2386)
Almost every unkind interviewer I’ve worked with has been either suffering from interview burnout after doing many interviews per week for many months or has been busy with other work to the extent that they have started to view interviews as a burden rather than a contribution. To fix that, give them an interview sabbatical for a month or two, and make sure that their overall workload is sustainable before moving them back into the interview rotation. (Location 2390)
The second critical step toward an effective interview loop is ensuring that everyone agrees on the role they are interviewing for, and what extent of which skills that role will require. (Location 2396)
For some roles— especially roles that vary significantly between companies, like engineering managers, product managers, or architects— this is the primary failure mode for interviews, and preventing it requires reinforcing expectations during every candidate debrief in order to ensure interviewers are “calibrated.” (Location 2397)
I’ve found that agreeing on the expected skills for a given role can be far harder than anyone anticipates, and it can require spending significant time with your interviewers to agree on what the role requires. (This is often in the context of what extent and kind of programming experience is needed in engineering management, DevOps, and data science roles.) (Location 2400)
After you’ve broken the role down into a certain set of skills and requirements, the next step is to break your interview loop into a series of interview slots that together cover all of those signals. Typically, each skill is covered by two different interviewers to create some redundancy in signal detection, in case one of the interviews doesn’t go cleanly. (Location 2404)
Prepared presentations on a topic. Instead of asking the candidate to explain some architecture on the spur of the moment, give them a warning before the interview that you’ll ask them to talk about a given topic for 30 minutes, which is a closer approximation of what they’d be doing on the job. Debugging or extending an existing codebase on a laptop (ideally on their laptop). This is much more akin to the day- to- day work of development than writing an algorithm on the board. A great problem can involve algorithmic components without coming across as a pointless algorithmic question. (One company I spoke with had me implement a full- stack auto- suggest feature for a search inbox, which required implementing a prefix tree, but the interviewer avoided framing it as yet another algo question.) Giving demos of an existing product or feature (ideally the one they’d be working on.) This task helps them learn more about your product and get a sense of whether they have interest around what you’re doing, and it helps you get a sense of how they deliver feedback and criticism. Roleplays (operating off a script that describes the situation.) This option can be pretty effective if you can get the interviewers to buy into it, allowing you to get the candidate to create more realistic behavior (architecting a system together, giving feedback on poor performance, running a client meeting, and so on). (Location 2409)
If you know the role you’re interviewing for and know the signal which your interview slot is listening for, then the next step is showing up prepared to find that signal. Being unprepared is, in my opinion, the cardinal interview sin, because it shows a disinterest in the candidate’s time, your team’s time, and your own time. When I recall the fortunately rare situations when I’ve been interviewed by someone who was both rude and unprepared, I still remember the unprepared part first and the rude part second. (Location 2423)
I’ve also come to believe that interview preparedness is much more company- dependent than it is individual- dependent. Companies that train interviewers (more on that below), prioritize interviewing, and maintain a survivable interview- per- week load tend to do very well, and other companies just don’t. (Location 2427)
Make sure your candidates know that you’re excited about them. I first encountered this idea reading Rands’s “Wanted” article, 4 and he does an excellent job of covering it there. The remarkable thing is how few companies and teams do this intentionally: in my last interviewing process, three of the companies I spoke with expressed interest exceptionally well, and those three companies ended up being the ones I engaged with seriously. (Location 2432)
Whenever you extend an offer to a candidate, have every interviewer send a note to them saying that they enjoyed the interview. (Compliment rules apply: more detailed explanations are much more meaningful.) At that point, as an interviewer, it can be easy to want to get back to your “real job,” but resist the temptation to quit closing just before you close: it’s a very powerful human experience to receive a dozen positive emails when you’re pondering if you should accept a job offer. (Location 2436)
Interviewing is not a natural experience for anyone involved. With intentional practice you’ll slowly get better, but it’s also easy to pick up poor interviewing habits (asking brainteaser questions) or keep using older techniques (whiteboard coding). (Location 2441)
The fix for all these issues is to ensure that you build feedback loops into your process, both for the interviewers and for the designer of the interview process. Analytics (discussed in the next section) are powerful for identifying broad issues, but pair interviews, practice interviews, and weekly sync- ups between everyone strategically involved in recruiting (depending on your company’s structure, this might be recruiters and engineering managers, or something else) work best to actively improve your process. (Location 2444)
For pair interviews, have a new interviewer (even if they are experienced somewhere else!) start by observing a more experienced interviewer for a few sessions, and then gradually take on more of the interview until eventually the more senior candidate is doing the observing. Since your goal is to create a consistent experience for your candidates, this is as important for new hires who are experienced interviewing elsewhere as it is for a new college grad. (Location 2448)
To get the full benefit of calibration and feedback, after the interview have each interviewer write up their candidate feedback independently before the two discuss the interview and candidate together. Generally, I’m against kibitzing about a candidate before the group debrief, in order to reduce bias in later interviews based on an earlier one, but I think this is a reasonable exception since you’ve experienced the same interview together. Also, in a certain sense, calibrating on interviewing at your company is about having a consistent bias in how you view candidates, independently of who on your team interviews them. (Location 2451)
For direct feedback from candidates, I’ve started to ask every candidate during my “manager interview” sessions how the process has been and what we could do to improve. (Location 2458)
Once you have the basics down, the final step of building a process that remains healthy for the long haul is instrumenting the process at each phase (sourcing, phone screens, take- home tests, onsites, offers, and so on) and monitoring those metrics over time. If your ratio of sourced referrals to direct ones goes down, then you probably have a problem (specifically, probably a morale problem in your existing team). And if your acceptance rate goes down, then perhaps your offers are not high enough, but it also might be that your best interviewer has burned out on interviewing and is pushing people away. (Location 2467)
I’ve put optimizing your funnel— and by this I include the entire process of building explicit analytics around your process— as the last priority in building a great interviewing process. From a typical optimization perspective, you should always measure first and optimize second, and here I’m giving the opposite advice. (Location 2472)
the most important aspect to interviewing well is to budget enough time and to maintain a healthy skepticism about the efficiency of your current process. Keep iterating forward and your process will end up being a good one. (Location 2479)
The three biggest sources of candidates are referrals from your existing team, inbound applicants who apply on your jobs page, and sourced candidates whom you proactively bring into your funnel. (Location 2484)
Small companies tend to rely on referrals, and large companies tend to rely on sourcing candidates, using dedicated recruiting sourcers for whom this is their full- time job (often the first rung on a recruiter career ladder). Medium- sized companies are somewhere on the continuum between those extremes. (Location 2486)
drawbacks. The first is that your personal network will always be quite small, especially when you consider the total candidate pool. This is especially true early in your career, but it’s easy to work for a long time without building up a large personal network if you work in a smaller market or at a series of small companies. (One of the side benefits of working at a large company early in your career, beyond name recognition, is kickstarting your personal network.) The other issue is that folks tend to have relatively uniform networks, composed of the individuals they went to school with or worked with. By hiring within those circles, it’s easy to end up with a company whose employees think, believe, and sometimes even look similar. (Location 2496)
Many hiring managers freeze up when their referral network starts to dry up, or as they look to bring a wider set of backgrounds onto their teams. However the good news is that there is a simple answer: cold sourcing. Cold sourcing, a technique that’s also common in some kinds of sales, is reaching out directly to people you don’t know. (Location 2504)
Join LinkedIn. I suspect variations of this technique would work on other networks (e.g., GitHub), but the challenge is that folks on other networks are generally not looking to engage about employment opportunities, and intent increases response rate significantly! A good parallel here is search versus display advertising, where search advertising has click- through rates that are an order of magnitude higher, as candidates are actually searching for what is being advertised. Build out your network by following individuals you actually do know. Add everyone that you went to school with, have worked with, have interacted with on Twitter, etc. It’s important to seed your network with some people you know because it’ll increase the reach of your second- degree network, and it’ll also reduce the rate at which folks mark you as someone they don’t know (which is an input to being penalized as a spammer). Be patient. If your initial network is small, it’s very likely that you’ll get throttled pretty frequently. Once you’re throttled (you’ll get a message along the lines of “You’ve exceeded your search capacity for this month”), you’ll have to wait for a few days, potentially until the next month, to unthrottle. Alternatively, you could sign up for their premium products, which would accelerate this quite a bit. It may take weeks or months of occasional effort (schedule an hour each week) to get your network large enough that you’re able to perform more than a few searches without rate limiting. Anecdotally, the number of connections at which things seem to get easier is around 600 or so. Use the search function to identify second- degree connections to connect to. Start out by searching in your second- degree network by job title— software engineer or engineering manager— and as your network expands, consider switching from title to company. (Consider the various lists of great companies5 in order to find companies to search by.) Build a broad church of connections! Even people whom you don’t reach out to now are folks who might reach out to you later, or whom you might reach out to in a few months as your hiring priorities change. If you’re not sure, just go ahead and do it. When someone accepts your connection request, grab their email address from their profile and send them a short, polite note inviting them to coffee or a phone call, and sharing with them a link to your job description. Experiment with varying degrees of customization. (Location 2521)
It’s worth noting that you will end up connecting with some folks whom you simply don’t have a great fit for right now. That’s okay. I recommend reviewing their profile pretty rigorously after they accept your connection, and making an honest assessment on fit. If you don’t have something, that’s okay, and it’s a better use of the candidate’s time to not reach out to them. (However, I also think we tend to over- filter on qualities that don’t matter too much! Being respectful of the candidate’s time is, in my opinion, the most important thing to optimize for.) (Location 2555)
Schedule and enjoy your coffees and chats, and remember that even people you aren’t able to work with now are still folks you’re likely to work with next year or next job. Especially in Silicon Valley, it’s a very small network, and you should interact with each person as if they’ll be providing feedback on whether or not to hire you at your next job. (They very well might!) You have two goals for each of these calls or coffees: figure out if there is a good mutual fit between the candidate and the role, and, if there is a good fit, try to get them to move forward with your process. The three things I find most useful to individuals deciding deciding to move forward with our process are describing why I personally am excited about the company and role we’re discussing, explaining how our process works (from our initial chat all the way to them receiving an offer) and then leaving ample time for them to ask questions. Keep spending an hour each week adding more connections and following up with folks who have connected. It’s a bit of a grind at times, but it’s definitely a practice that rewards consistency. I’ve found that this is a good activity to do together! Have a weekly meeting of coworkers who come together and source, chatting about how you’re evolving your search. This also helps folks overcome their initial discomfort with cold reach- outs. (It’s worth pointing out that this process is much easier to do with an applicant tracking system (ATS) like Lever6 or Greenhouse, 7 which allow you to have a single place to track whether a candidate has already been contacted by someone else at your company. Having a bunch of folks from the same company reach out around the same time can paint a picture of chaos.) (Location 2560)
I would be cautiously concerned if an engineering manager was spending more than an hour a week on sourcing (not including follow- up chats, as those will take up a bunch more time). There is also a lot of important work to be done closing and evaluating candidates well, in addition to the numerous non- hiring- related opportunities to be helpful. (Location 2582)
the single clearest indicator of strong recruiting organizations is a close, respectful partnership between the recruiting and engineering functions. Spending some time cold sourcing is a great way to build empathy for the challenges that recruiters face on a daily basis, and it’s also an excellent opportunity to learn from the recruiters you partner with! We’ve been doing weekly cold sourcing meetings as a partnership between our engineering managers and engineering recruiters, and it’s been a great forum for learning, empathy- building, and, of course, hiring. (Location 2584)
The hiring funnel consists of four major steps: identifying candidates, motivating them to apply, evaluating them for your company, and closing them on joining. Depending on your particular circumstances, any or all of these can be very challenging. (Location 2595)
Identify Candidates tend to come from three large buckets: inbound, sourced, and referrals. Slower- growing and early companies tend to rely heavily on referrals, whereas fast- growing companies tend to exhaust their supply of referrals and to rely more heavily on sourcing and inbound. Inbound are candidates who apply to you directly. These come from your jobs website, often administered using an applicant tracking system like Greenhouse or Lever, or from job postings on LinkedIn and other job sites. Inbound tends to be high volume and low quality. The exception is for companies with powerful external brands, typically the culmination of strong product, reputation, and outreach. Sourced are candidates whom you proactively find and engage. The most common approaches are using LinkedIn, visiting colleges, and networking at conferences and meetups. Referrals are candidates whom someone at your company already knows, typically previous coworkers or friends who attended college together. This tends to be the primary source of hires for smaller companies. At most companies, referrals are the most efficient source of candidates, sporting the highest rate of interviews that lead to job offers. (Location 2597)
Motivate Once you’ve identified candidates you want to consider joining with your company, you need to motivate them to come interview! Some companies prefer to view this phase as a filter to weed out folks who are insufficiently passionate about their work, but I’ve not found that approach very effective. Rather, that approach seems to mostly filter for candidates willing to represent enthusiasm, as opposed to finding authentic passion. Instead, the formula that I’ve found most effective is pretty simple: Spend time. Have the people the candidate would work with spend time with them. Grab coffee with them, talk about the projects they’re working on, and get them excited about learning from each other. Clearly define the role. Tell the candidate about what they’d be doing, being both very honest and a bit optimistic. That is to say, always give an accurate description of the work, but try to find the best frame for describing the work. (Location 2607)
Evaluate Once you’re blessed with individuals who want to consider working with you, the next phase is to ensure that they’ll be successful additions to your team. This phase is tricky because you’re balancing quite a few objectives, some of which are in conflict: Certainty. You want to be as confident as possible that the candidate will be a success in your company. Letting employees go can be hard on morale, and it takes a great deal of time to do well. Candidate experience. You want candidates’ motivation to join your company to increase as they’re evaluated, not decrease. One of the worst possible outcomes of your hiring funnel is that you identify folks you want to join your company, but they’re no longer interested in being part of it. Efficiency. You also want to minimize the amount of time invested by both your team and the candidate. How you think about this can lead to significant asymmetries, such as take- home assignments that require significant candidate time but little in- house time for evaluation (well, in principle anyway, since it seems like most folks find take- home assignments quite slow to review thoroughly). (Location 2616)
• Close This is similar to the motivate phase, but now instead of asking them to commit a day, you’re asking them to commit a couple years of their life. Many, many factors come in to play, from compensation packages to benefits, to making them feel needed. Because this is the final step, doing well here is an especially important factor in your funnel efficiency. When you want to start operationalizing your hiring process, the first step is to craft a process for how candidates will flow through this funnel. (Location 2625)
Instrumentation is so important because it allows you to understand where to focus your efforts. Different companies excel at different aspects, and even the same company will become better and worse at different stages over time. The only way to operate a consistently good hiring funnel is to ground your attention and efforts in your funnel metrics. Once you do have the metrics, put your effort where there is the most room to improve. The first step of this is quite literal, looking at the conversion rates across each phase and investing. But what’s slightly less obvious is what the reasonable upper bounds for each section should be. To answer those questions, benchmarking against your peer companies is really the only way to get useful information. If you don’t benchmark, you can find yourself investing beyond diminishing returns in motivating candidates to interview, close, etc. Whenever you have a hiring challenge, start from your instrumented hiring funnel and work the problem systematically from there! (Location 2633)
Instead of ending your funnel at closing candidates, add four more phases: Onboard. How long does it take new hires to get up to speed? It’s pretty tricky to measure this, but since you’re trying to reason about the population rather than individuals, it’s okay to be a bit messy. Pick a productivity metric, maybe commits per week, and see how long it takes for new hires to reach P40 productivity. That’s a sufficiently good measure for understanding how long it takes folks to ramp up. (Location 2645)
Impact. How impactful are the people that you’re hiring? Again, that’s a tricky one to measure, but you’re looking to understand trends, not individuals, so don’t worry about identifying perfect metrics. A reasonably good proxy here is looking at the performance rating distribution for new hires based on time since hiring. (Location 2649)
Promote. How long does it take individuals to get promoted after they’re hired? This is useful for understanding whether employees have access to opportunity8 within your organization. (Location 2652)
Retain. Are the people you hire staying? Fortunately, this one is pretty easy to track by looking at the people who leave. It is, however, quite a lagging indicator, since it typically takes years for folks to leave. Still, I believe that it’s an essential metric to track. (Location 2654)
The most sacred responsibilities of management are selecting your company’s role model, identifying who to promote, and deciding who needs to leave. At small companies these decisions tend to be fairly ad hoc, but as companies grow these decisions solidify into a formal performance management system. (Location 2661)
If you want to shape your company’s culture, inclusion, 9 or performance, this is your most valuable entry point. The number of approaches to performance management is uncountably vast, but most of them are composed of three elements: (Location 2663)
Career ladders describe the expected evolution an individual will undergo in their job. For example, a software engineer ladder might describe expectations of a software engineer, a software engineer II, a senior software engineer, and a staff engineer. Performance designations rate individuals’ performance for a given period against the expectations of their ladder and level. Performance cycles occur once, twice, or four times a year, with the goal of assigning consistent performance designations. (Location 2666)
At the foundation of an effective performance management system are career ladders, which describe the expected behaviors and responsibilities for a role. There is significant overhead to each career ladder that you write and maintain, and also a significant downside to attempting to group different roles onto a shared ladder. (Location 2674)
What I’ve seen work best is to be tolerant of career ladder proliferation— really try to make a ladder for each unique role— but to only invest significant time in refining any given ladder as it becomes applicable for more employees. (Location 2677)
One effective method for reducing the fixed cost of maintaining ladders is to establish a template and shared themes across every ladder. Not only does this reduce fixed maintenance costs, it also focuses the company on a set of common values. Each ladder is composed of levels, which describe how the role evolves in responsibility and complexity as the practitioner becomes more senior. The number of levels appropriate will vary across ladders, function size, and function age. Most companies seem to start with three levels and slowly add levels over time, perhaps adding one every two years. At each level, you’ll want to specify the expectations across each of your values. Crisp level boundaries reduce ambiguity when considering whether to promote an individual across levels. Crisp boundaries are also important as they provide those on a ladder a useful mental model of where they are in their journey, who their peers are, and whom they should view as role models. The level definitions are quite effective at defining the behaviors you’ll want in your role models, which are the behaviors you’ll see everywhere a year or two later. (Location 2684)
A good ladder allows individuals to accurately self- access; these ladders are self- contained and short. A bad ladder is ambiguous and requires deep knowledge of precedent to apply correctly. If there is one component of performance management that you’re going to invest into doing well, make it the ladders: everything else builds on this foundation. (Location 2693)
Once you have the career ladders written, the next step is to start applying them. The most frequent application will be using them as a guide for self- reflection and during career coaching one- on- ones, but you’ll also want to create formal feedback in the form of a performance designation. (Location 2697)
A performance designation is an explicit statement of how an individual is performing against the expectations of their career ladder at their current level over a particular period of time. Because these designations are explicit, they are a backstop against miscommunication between the company and an employee. However it is a cause of concern and debugging if the explicit designation doesn’t match the implicit signals someone has received. (Location 2699)
Most companies start out using a single scale to represent performance designations, often whole numbers from one to five. Over time, these often move toward the nine- blocker format, a three- by- three grid with one axis representing performance and the other representing trajectory. Having used a number of systems, I prefer to use the simplest representation possible. The extra knobs in more complicated systems support more granularity, but my sense is that they simply create the impression of rigor while remaining equally challenging to implement in a consistent, fair way. (Location 2702)
Self- review is written by the individual receiving the designation. The best formats try to explicitly compare and contrast against their appropriate ladder and level. I’ve also seen good success in the “brag document” 10 format. Peer reviews are written by an individual’s peers, and are useful for recognizing mentorship and leadership contributions that might otherwise get missed. Structured properly, they are also useful for identifying problems that you’re missing out on, but peers are generally not comfortable providing negative feedback. Upward reviews are used to ensure that managers’ performance includes the perspective of the individuals they manage directly. Format is similar to peer review. Manager reviews are written by an individual’s manager, typically a synthesis of the self- peer, and upward reviews. (Location 2708)
Calibrations are rounds of reviewing performance designations and reviews, with the aim of ensuring that ratings are consistent and fair across teams, organizations, and the company overall. (Location 2718)
happen at each level of the organizational tree. It’s pretty challenging to strike the balance between avoiding calibration fatigue from many sessions and ensuring that the people doing the calibration are familiar with the work they are calibrating. Promotions are typically also considered during the calibration process. Calibrations fall soundly in the unenviable category of things that are terrible but have no obvious replacement. (Location 2722)
rules that I’ve found useful for calibrations: Adopt a shared quest for consistency. Try to frame calibration sessions as a community of coworkers working together toward the correct designations. Steer them away from anchoring on the designations they enter with, and toward shared inquiry. Doing this well requires a great deal of psychological safety among calibrators, which needs to be cultivated long before they enter the room. 11 (Location 2727)
Read, don’t present. Many calibration systems depend heavily on whether managers are effective, concise presenters, which can become a larger factor in an individual’s designation than their own work. Don’t allow managers to pitch their candidates in the room, but instead have everyone read the manager review. This still depends on the manager’s preparation, but it reduces the pressure to perform in the calibration session itself. (Location 2731)
Compare against the ladder, not against others. Comparing folks against each other tends to introduce false equivalencies without adding much clarity. Focus on the ladder instead. (Location 2735)
Study the distribution, don’t enforce it. Historically, many companies fit designations to a fixed curve, often referred to as stack ranking. 12 Stack ranking is a terrible solution, but here’s the problem it tries to address: it’s easy for the meaning of a given designation to skew as a company grows. Instead of fitting to a distribution, I find it useful to review the distributions across different organizations and to discuss why they appear to be deviating. Are the organizations performing at meaningfully different levels, or have the meanings skewed? (Location 2737)
feedback for weak performance should be delivered immediately. Waiting for performance designations to deal with performance issues is typically a sign of managerial avoidance. That said, it does serve as an effective backstop for ensuring that these kinds of issues are being addressed. (Location 2745)
Most companies do either annual or biannual performance cycles, although it’s not unheard of to do them quarterly. The overhead of running a cycle tends to be fairly heavy, which leads companies to do them less frequently. Conversely, the feedback from the cycle tends to be very important, and it serves as a primary input into factors that individuals care about a great deal, like compensation, so there is also countervailing (Location 2750)
Laszlo Bock’s Work Rules! 13 is a good read. (Location 2764)
Designation momentum. This is the term for the natural tendency of a performance process to consistently produce the same evaluations for the same people despite changes in performance. If you are receiving good designations, this is an exciting phenomenon, because it means you are likely to continue receiving them. But I find that this is unexpectedly somewhat demotivating for high performers, who want consistent, direct feedback on their work so that they can keep improving. Those receiving poor designations, unsurprisingly, find this phenomenon quite frustrating, in particular because it makes it challenging for them to determine if it’s a lagging indicator of a previous issue or if they’re continuing to do poorly. (Location 2776)
Propose a set of clear goals to your manager, and iterate together toward an explicit agreement on the expectations to hit the designation you’re aiming for. The goals need to be ambitious enough that your manager can successfully pitch the difficulty to their peers during calibration. If your manager is pushing back on your goals’ ambition, that is probably their way of saying that they think their peers will challenge their difficulty. That doesn’t mean your plan isn’t difficult enough— it may well be very appropriate— but it does mean you’ll have to work to help them explain why the goals are appropriate. (Location 2783)
Designation momentum occurs for individuals, but it also happens for teams and organizations. For teams in this position, setting clear goals is a good start, but it’s also necessary to align with your peers and leadership about why your work is important. It’s your work as a leader to explain why your work is important in terms that the organization understands and appreciates. This is a good example of where the failure to do so will have long- running costs. (Location 2788)
Tit for tat. Calibration systems without strong process and fair referees can degrade into tit- for- tat favor trading. It’s very rare to see active collusion during calibration; rather, the most common case occurs when folks are silent instead of raising concerns. This silence may seem benign, but it isn’t: it pushes all responsibility for consistent outcomes onto the individuals refereeing the calibration process. Encouraging engagement requires the calibration referee to model the behavior, but more importantly, it depends on building psychological safety and trust across the folks who are calibrating together. (Location 2791)
Level expansion. As a company ages, it will inevitably add levels to support career progression. This happens even if a company remains the same size, and it’s primarily driven by company age, not size. This is frequently driven by a small cohort of the highest- level executives. If a company is experiencing particularly frequent level expansion, it is usually a sign that progression, compensation, or recognition has been overly tied to your level system, and you should identify mechanisms to reduce pressure on leveling. Training and education are useful here, as is getting more structured in assigning important projects. (Location 2797)
The other scenario that typically leads to level expansion is one in which very senior executives from other, typically older, companies are hired. These people benefited from level expansion as that company aged, and it’s hard for them to walk away from that heady cocktail of status, compensation, and recognition. (Location 2802)
Level drift. Because level expansion is typically driven more by the need for career progression than by the introduction of objectively distinct accomplishment, levels added at the top create downward pressure on existing levels. Expectations at a given level decrease over time. This inflation feels uncomfortable because we often rely on scarcity to determine value, but it’s very uncommon for companies to adjust compensation in response to level drift. Thus, in practice, it is a rising tide that raises all boats. From a company perspective, it’s important to manage level drift explicitly, so that it’s possible to apply the shifts consistently. (Location 2804)
The combination of level expansion and level drift leads to periodic bursts in which a cohort of individuals cross level boundaries together. This happens most frequently at the second- highest level, one or two cycles after a level expansion. As a manager, you need to coordinate with your peers to ensure that you are opening the gate together in a consistent fashion. It’s easy to miss these moments, but if you do you may inadvertently eject individuals from their natural cohort of peers. You can usually fix this in a subsequent cycle, but you’ll have missed out on momentum. After each cycle, take an hour and try to guess when the gates might open next, and talk with your peers about it. (Location 2810)
Career level. For every role, a given level will be established as the career level, and most individuals are not expected to progress beyond that level. Over time, this often leads to career level clustering, with the normal distribution centered on the career level, as opposed to the typical goal of the distribution centering at mid- level. (Location 2816)
Time- at- level limits. Employees who haven’t yet reached career level are expected to progress toward the career level at a consistent pace. This is typically used as a backstop for situations in which performance management seems appropriate but is not occurring. My experience is that most companies have time- at- level limits, but that there are many other ways to accomplish the same goals; such limits are useful as part of an overall system, but they aren’t necessary in many configurations. The only bit I’ve found predictably important here is being consistent in how they are applied. (Location 2819)
Level split. Over time, it is common for the career level to experience level drift, leading to increasingly distinct clusters of workers who reached career level at its highest expectations and those who have reached it recently. Given the greatly elevated expectations beyond the career level, upward mobility remains evasive. Many companies decide to perform a level split: separating the career level into two halves. This allows the distinct cohorts to inhabit distinct levels, and it extends the runway of career progression for most employees. Less obviously, the split tends to solidify the moat guarding access to post- career levels. The extended moat doesn’t catch those right on the border. It’s easy to handle these folks properly, but the moat absolutely does slow the progression for the cohort who were about a year away from changing levels. (Location 2823)
Crisis designations. These are alternatively known as retention- driven designations. Sometimes companies find themselves in a difficult situation, in which they have key individuals or even key teams that they consider to be at- risk, and one of the tools for addressing the situation is to recognize these individuals’ importance through elevated performance designations. These are intended as temporary, but they tend to reset expectations permanently in ways that sacrifice long- term usefulness of the performance system in order to manage through short- term difficulty. Sometimes stuff gets really hard, and if that’s the case, then use the tools at your disposal, but generally try to avoid doing this if possible. (Location 2832)
The major challenges I’ve encountered rolling out new roles are: Class systems. Folks often look at new roles as less important, framing them as service roles to absorb work they’re not interested in. Sometimes roles are even explicitly designed this way, intended to reduce work for another role as opposed to having an empowering mission of their own. Brittle organization. As you move away from generalized roles and toward specialists, an unexpected consequence is that your organization has far more single points of failure. Where everyone on a team was once able to perform all tasks fairly effectively, now if your project manager leaves, you’ll find that no one is able to fill the role very capably. This brittleness is particularly acute in organizations with frequent structural changes. 18 Pattern matching. Designing a new role for your organization tends to involve dozens of important decisions in order to align it with your needs. Unfortunately, folks generally don’t take much time to appreciate these distinctions, and instead pattern match on how they’ve seen the role done elsewhere. This is a powerful force. Some meaningfully large percentage of people will both avoid taking any steps to learn how the role is intended to function— reading documentation, asking about the approach— and continue to express surprise that it doesn’t work exactly the way they saw at a previous company. Task offloading. When a new role is created, the role’s designers have a very clear vision of how they want the new function to work. Many other individuals are not particularly concerned with how the creators want the function to work, and will view it as an opportunity to offload tasks that they find challenging, difficult, or uninteresting. This can lead to new roles being immediately underwater, which often feels like success to leaders attempting to grow the size of their organization. However, that can can easily translate into an unlovable work experience for those performing the role. Roles too “trivial” to value. Many roles start by taking on work that is viewed as uninteresting by the role shedding that responsibility, and consequently individuals in that role tend to view that work as trivial and unimportant. This often translates into the new roles struggling to have their impact be recognized. Roles too “trivial” to promote. Similar to the above, you’ll often find that the work done by new roles is valued very highly in terms of impact, but not viewed as sufficiently “strategic” to merit promotion, particularly beyond career level. 19 This can lead to individuals being obligated to change roles if they want to attain higher tiers of achievement. Head count obstacles. Companies eventually develop arcane rituals by which a series of emails, meetings, and incantations is translated into an annual head count plan. These systems are, quite reasonably, designed around supporting the needs of large, existing roles. Consequently, they tend to make it pretty challenging to get head count for a new role, particularly if it’s in tension with existing functions that need to expand. Recruiting rare humans. For entirely great reasons, people want the first hires they make into a new role to be strong role models for the entire function. This often leads to a proliferation of requirements until it’s impossible for any candidate to pass the bar. Inability to evaluate. This is almost the opposite of the above challenge: sometimes the existing organization has so little experience with the new function they wish to create that they simply don’t have a usable means by which to evaluate candidates. This can lead to evaluations focused on qualities that are largely independent of what the candidates would be doing if they accepted the job. (Location 2862)
If we do want to create a new role, it’s important to take stock of what we’ll need to do to make employees in the role successful. The ingredients that I’ve found necessary for a new role to bootstrap successfully are: Executive sponsor. Not necessarily an executive, but you’ll need to find an authorized, senior leader who is committed to the success of the new function. Especially for the first performance20 and head count cycles, there will be a number of rough edges that will require significant organizational support to navigate. The need to find a sponsor who’ll be able to provide the necessary support is the most obvious constraint on creating new roles. If you can’t find a sponsor, it’s usually important feedback that leadership doesn’t believe the new role will have a good return on invested energy. Recruiting partner. A new role will require significant support from your recruiting organization in order for it to succeed. Every role being recruited against has a high fixed cost, and adding new roles can make it difficult for recruiters to hit the targets that their performance is measured against. Make sure that your recruiting team is able to support a new role! If they aren’t, the first step may be working with your executive sponsor to direct more head count toward recruiting. Self- sustaining mission. New roles are frequently described in terms of how they’ll impact other functions, rather than in terms of what they’ll accomplish. For example, you might describe technical program managers (TPMs) as offloading project management responsibilities from engineering managers. This approach frames the role as an auxiliary, support function, which makes it difficult to recognize the work’s impact. You must be able to frame the role’s work without referencing other existing roles in order for it to succeed long- term. Career ladder. In pretty much all cases, new roles should have a career ladder from the beginning. The career ladder is the foundation of a successful performance management system, and it’s not possible for a role to be valued or evaluated coherently without a thoughtful career ladder. Sometimes folks rush ahead to hire before writing the ladder, but the work required to design an effective interview loop is roughly equivalent to writing a career ladder, so I’ve found that skipping this step is an act of false economy. Role model. Who will be the external and internal role models for this role? A good role model is a human embodiment of the intent codified in your career ladder. You want to have a person you can point to. Dedicated calibrations. Most performance management systems rely on a calibration system to ensure that performance designations are being assigned in a consistent fashion across teams and roles. Sometimes managers try to perform calibration with mixed roles in a single session, which leads to smaller roles being treated as afterthoughts. Often the designations will be approved without much thought, or they’ll be pushed toward the center. Neither of those scenarios creates a useful feedback loop for the individual in the new role. It’s best to consider them separately in a dedicated calibration session for the one role. If that’s not possible, the second- best option is to consider all smaller roles together, so that various forms of specialized contributions can be considered thoughtfully. (Location 2894)
Efficiency. This is the flip side of brittle organization: people in specialized roles are able to spend more time doing a smaller set of tasks, which leads to great expertise in that area. For areas where existing roles are spending significant amounts of time, this specialized efficiency can translate into significantly more overall throughput without increasing head count. I think this is the most important advantage, and it’s especially valuable for teams or companies in which financial resources are the limit on growth (which is most teams at most companies). Efficiently solve constraints. This is an extension of the efficiency point, but subtly different: with specialists, you can add exactly the kind of capacity you are missing, which is very powerful for efficiently solving constraints. If your organization is low on project management bandwidth, you could add five new managers who can each take on a bit of it, or you might be able to add a single project manager who individually adds as much relevant bandwidth as the five managers combined. Recognition. Simply creating a new role will absolutely not cause folks to suddenly start valuing work that they previously dismissed, but it can be a useful component in that shift. In particular, it will provide additional structural mechanisms to support recognition, such as distinct career ladders, calibration sessions, and even compensation structures. Evaluating for strengths. It’s often challenging to interview specialists effectively, because you’ll typically evaluate them based on how they’d perform for your generalist position, while missing out on their peculiar areas of excellence. Creating a new role makes it possible to target the interview process on the areas that are most important. Increased hiring pool. You’re now able to consider a new pool of candidates in your hiring funnel, 21 and that potentially expands the total number of candidates you can consider. Specialized compensation. In some cases, the market compensation for specialists is significantly higher than that for generalists, and in that case it’s often quite a challenge to hire specialists without specialized compensation bands. (Location 2924)
Is there a less extreme way to address the recognition gap? Maybe you could adjust the existing career ladder instead. Do you have a plan for changing how the company values the work? Creating a new role won’t inherently change how the company values this work. You’ll still need to do the hard work of expanding your company’s values. If you have a plan to change company values, could you do a trial run of that plan before introducing the new role? This helps de- risk the experiment for the folks you are trying to help, and it’s much easier to boot. Does the function already exist in secret? Sometimes you’ll find that roles have already split, and you’re less making a new function than recognizing an existing one. Will this increase short- term recognition of performance but ultimately hurt the career growth of employees who change roles? Creating a new role is absolutely the kind of thing that can initially feel like progress but ultimately sets folks back significantly, requiring them to transition to other roles later. Is the number of people impacted sufficiently high and is the recognition gap of value significantly large, to cover the sizable costs of creating and nurturing a new role? Who will pay the maintenance costs for the new role? If the answer is that you’ll personally pay them, who will take up the torch if you leave? (Location 2945)
As a rule of thumb, I would always create a new role if it immediately covered 20 individuals; would reluctantly create a new role if it would cover 20 individuals within two years; and would be skeptical of creating a new role that couldn’t meet one of those two conditions! (Location 2957)
Anyone who has flipped through Cracking the Coding Interview by Gayle Laakmann McDowell22 knows that evaluating candidates for a new role is a coarse science. Most interviewers are skeptical of the accuracy of their interviews, and it’s hardly the rare interview retrospective where interviewers aren’t sure they got enough signal on a candidate to hire with confidence. (Location 2960)
Although a dose of caution about interview accuracy is well- founded, I’m increasingly convinced that a bit of structure and creativity leads to interview loops that give a clear signal on whether a candidate will succeed in the role, and whether they can do so in a fair and consistent fashion. (Location 2964)
Metrics first. Do not start designing a new interview loop until you’ve instrumented your hiring funnel. 23 It’s pretty hard to evaluate your loop or improve it without this data, so don’t undertake an improvement project without it. (Location 2967)
Understand the current loop’s performance. Take time to identify what you think does and doesn’t work well in your current process. Three sources that are useful are: Funnel performance. Where do people drop off in your funnel? How does your funnel benchmark against your peers at similar companies? Employee trajectory. For all the candidates you have hired, understand how their work performance relates to their interview performance. What elements correlate heavily with success, and which appear to filter on things that end up not contributing to performance in the job? Candidate debriefs. Try to schedule calls with everyone who goes through your process, especially with those who drop out. (Location 2970)
Learn from peers. Chat with folks who have interviewed at other companies for the kind of role you’re hoping to evaluate. You’re not looking to copy elements verbatim, but rather to get a survey of existing ideas. (Location 2976)
Find role models. Write up a list of ideal candidates for the role and write down what makes them ideal. Be deliberate about ensuring that your list of role models includes women and underrepresented minorities, helping avoid matching on correlating traits in a less diverse set of role models. (Location 2978)
Identify skills. From your role models and your career ladder, 24 identify a list of skills that are essential to the candidate’s success in the role they’ll be interviewing for. Take a bit of time to rank those skills from most to least important. (Location 2980)
Test for each skill. For each skill, design a test to evaluate the candidates’ strengths. Whenever possible, prefer tests that have a candidate show their strengths, avoiding formats in which they tell you about it. (Location 2983)
Avoid testing for polish. Many interviews accidentally test for the candidate’s polish as opposed to testing for any particular skill. This is especially true for experiential interviews in which folks are asked to describe their work, and less common in interviews that ask them to demonstrate skills. That isn’t to say that you shouldn’t deliberately test for polish— it’s quite useful— just that you shouldn’t do it inadvertently. (Location 2987)
For each test, a rubric. Once you’ve identified your tests, write a rubric to assess performance on each test. Good rubrics include explicit scores and criteria for reaching each score. If you find it difficult to identify a useful rubric for a test, then you should look for a different test that is easier to assess. (Location 2990)
Avoid Boolean rubrics. Some tests tend to return Boolean results: for example, whether someone has experience managing someone is a good example of a common Boolean filter. These are inefficient tests because you pretty quickly get a sense of whether someone has or hasn’t ticked this box, and the rest of the interview doesn’t lend more signal. Likewise, you can almost always answer Boolean questions from an applicant’s resume or in a pre- interview screen. (Location 2993)
Group tests into interviews. Once you’ve identified the tests, group them into sets that can be performed together in a single 45- minute interview, or whatever duration you prefer. The more cohesive the format and subjects of the tests in a given interview, the more natural it’ll feel for the candidate. (Location 2996)
Run the loop. At this point you have an entire loop ready, and it’s time to start using it. Especially early on, you should be asking candidates what did or didn’t work well— but, really, you should never stop doing this! Each debrief will uncover some opportunities to improve your rubric or tests. (Location 2999)
Review the hiring funnel. After you’ve run the new loop 10 to 20 times, review the funnel metrics to see how it’s working out. Are some of the interviews yielding too many passes? Are others too hard? Review the results in batch. (Location 3002)
Schedule an annual refresh. As the initial rate of iteration slows down, schedule a review for a year out, and at that point you get to ask yourself if the loop has proven effective for your needs, or if you should restart this process! (Location 3004)
Try to avoid design by committee. These almost always lead to incremental change. Prefer a working group of one or two people that is then tested against a bunch of candidates for feedback! (Location 3007)
Don’t hire for potential. Hiring for potential is a major vector for bias, and you should try to avoid it. If you do decide to include potential, then spend time developing an objective rubric for potential, and ensure that the signals it indexes on are consistently discoverable. (Location 3009)
Use your career ladder. Writing a great interview loop is almost identical to writing a great career ladder. 25 If you’ve already written expectations for the role, reuse those as much as possible. (Location 3012)
Iterate on the interview a little. When you first create an interview, you should spend time iterating on the interview format, but the rate of change should drop to near- zero after you’ve given it approximately 10 times. (Location 3014)
Hiring committees. As an alternative to A/ B testing, I have found a centralized hiring committee that reviews every candidate’s interview experience to be quite valuable for identifying trends across new loops. More generally, this approach helps guide the overall process toward consistency and fairness. (Location 3022)
The criteria I use to evaluate if a team’s sprint works well: Team knows what they should be working on. Team knows why their work is valuable. Team can determine if their work is complete. Team knows how to figure out what to work on next. Stakeholders can learn what the team is working on. Stakeholders can learn what the team plans to work on next. Stakeholders know how to influence the team’s plans. (Location 3043)
One of my coworkers, Davin Bogan, 1 likes to say that “shipping is a habit,” and a well- run sprint both helps teams establish that habit and serves as a mechanism that creates visibility within a team that hasn’t quite gotten there yet. (Location 3050)
As your team gets larger and the number of stakeholders you’re working with grows, you’ll also want to develop a roadmap describing your high- level plans over the next three to twelve months. Planning does not inherently create value, so aim to keep your roadmap as short as possible and allow teams to coordinate. (Location 3059)
Thinking in Systems: A Primer by Donella H. Meadows For me, systems thinking has been the most effective universal tool for reasoning through complex problems, and this book is a readable, powerful introduction. (Location 3115)
Don’t Think of an Elephant! Know Your Values and Frame the Debate by George Lakoff While written from a political perspective that some might find challenging, this book completely changed how I think about presenting ideas. You may be tempted to instead read Lakoff’s more academic writing, but I’d recommend reading this first as it’s much briefer and more readable. (Location 3118)
Peopleware: Productive Projects and Teams by Timothy Lister and Tom DeMarco The book that has given generations of developers permission to speak on the challenges of space planning and open offices. Particularly powerful in grounding the discussion in data. (Location 3122)
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco Documents a compelling case for middle managers as the critical layer where organizational memory rests and learning occurs. A meditation on the gap between efficiency and effectiveness. (Location 3126)
The Mythical Man- Month by Frederick Brooks The first professional book I ever read, this one opened my eyes to the wealth of software engineering literature waiting out there. (Location 3129)
The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt Explores how constraint theory can be used to optimize process. (Location 3135)
The Three Signs of a Miserable Job by Patrick Lencioni Another Lencioni book, this one explaining a three- point model for what makes jobs rewarding. (Location 3139)
INSPIRED: How to Create Tech Products Customers Love by Marty Cagan A thoughtful approach to product management. (Location 3144)
Becoming a Technical Leader: An Organic Problem- Solving Approach by Gerald M. Weinberg Permission to be a leader that builds on your strengths, not whatever model that folks think you should fit into. (Location 3156)
“Big Ball of Mud” A reaction against exuberant publications about grandiose design patterns, this paper labels the most frequent architectural pattern as the Big Ball of Mud, and explores why elegant initial designs rarely remain intact as a system goes from concept to solution. From the abstract: While much attention has been focused on high- level software architectural patterns, what is, in effect, the de- facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of (Location 3212)
