Infographic for "Lessons from Jade Rubick".

On Leadership

  1. "The higher you go in an organization, the less you know what is going on. Yet, the higher you go in an organization, the more you're responsible for fixing what's going on." [3]
  2. "People don't lie to leaders to be malicious, they hide things that are problems or downplay things because it's often not safe for them to bring it up." [3]
  3. "Many people fetishize straight communication and feedback but don't understand what it takes to actually build a culture where it is safe (for everyone) to do that." [3]
  4. "Humans are hierarchical creatures. Like other apes, we naturally think of ourselves in hierarchy. Leaders are constantly deferred to. They have their ideas validated as brilliant... This reinforces confidence in leaders." [3]
  5. "If you're doing an important job you will end up being a bottleneck at some point. There is an art to disentangling yourself from doing things directly, and it's a skill and it's actually pretty hard to learn." [4]
  6. "What I see is that leaders struggle to balance their need to be involved with the fact that they can't do it all." [4]
  7. "I think the key framing for this is that you want to make your organization produce the outcomes the way you want instead of doing those things yourself." [4]
  8. "If you are an information hub where everything's coming through you you are necessarily going to be a bottleneck." [4]
  9. "What do you do when you don't have the authority to accomplish your goals? To answer that, I'd like to talk today about a concept I called reflecting power." [5]
  10. "Reflected Power is using the authority of those above you to amplify your influence and achieve your goals." [6]
  11. "Most leaders do not seem to be very good at seeing the long-term impact of things." [7]
  12. "You want all of your long-term trends to be heading in a positive direction, so that your flywheel of value delivery is getting faster over time." [7]
  13. "Organizational work is work that you do ON an organization, to make it more effective. Organizational work is a critical concept for leaders, a sort of “second job”."
  14. "If you don't invest in organizational work, what happens? The default drift in an organization is toward entropy and increasing complexity."
  15. "As your position in the company rises further and further up, the percent of your time spent on organizational work will naturally increase."
  16. On Leaders should code with humility: Engineering managers, directors, and VPs should code enough to understand agent-based development, but they must do it with humility rather than displacing or overriding their teams. — Aviator Podcast — Jade Rubick
  17. On Leadership: "Almost any metric that you use for evaluating people will be gamed in a way that is harmful. I don’t recommend using ValueSum to measure individuals or teams for bonuses or promotions." — Engineering Leadership

On Team and Culture

  1. "You want a leadership team not a group of individuals. so get your team to work with each other." [4]
  2. "If you're genuinely trying to make your company be a great place to work, you should talk about that." [8]
  3. "A good interview plan allows you to have confidence you'll vet and find the right candidate. A poor interview plan results in a terrible candidate experience." [8]
  4. "One tip: pair people up in the interviews. People learn from seeing others interview, so this will make your interviews automatically improve themselves." [8]
  5. "You shouldn't rely on hope as a strategy, but have a plan that identifies how you'll appeal to the best applicants you can attract." [8]
  6. "For especially promising candidates, you can even refer them to other companies, or make little suggestions on how they might improve their interviewing." [8]
  7. "The universe bends towards entropy, and it's only through good engineering and constant vigilance that we can even keep things running. It's a constant battle constant fight." [9]
  8. "We often had to do these hard pivots between reliability work and project work something would get so bad that our customers were so angry with us that we would just basically halt the world and focus on reliability work for a while." [9]
  9. "The idea was, it doesn't even matter if you have deadlines, you always do that work before you get back to your project work." [9]
  10. "When an incident would happen no matter what you had the space to do a little bit of work to prevent that from happening again or to make it not as bad next time." [9]
  11. "Let's talk about the magic of small things: delivering mini-features, fixing bugs. These things are often the difference between a poor product and something you're proud of." [10]
  12. "I also saw Tiny Thursdays as a useful way to keep a steady stream of value coming from engineering. Even if we're working on something larger, that will take a while, it ensures a continuous drip of value." [10]
  13. "Generally product teams find it very difficult to prioritize small things i think the reason for that is that prioritization has overhead." [11]
  14. "We tend to undervalue small things we don't actually see how valuable they can be." [11]
  15. "It seems to me that sometimes you can deliver these small mini projects that often deliver as much value as bigger projects." [11]
  16. On Role definitions: "A lot of engineering teams are feeling a squeeze where the expectations have risen considerably, but the role definition still hasn't really changed." — Aviator Podcast
  17. On Written culture: "Companies that have written cultures will see disproportionate gains over those that don't. The more a company is using written artifacts, the easier they will be able to set up a lot of business processes to be automated." — Aviator Podcast
  18. On Team and Culture: There is a significant body of evidence suggesting that using story points is not an effective way to track a team's output. — Engineering Leadership
  19. On Embed QA while engineering owns quality: When QA exists, embed it with the team as quality expertise while engineering retains ownership of quality; avoid transactional handoffs that slow feedback and weaken incentives. — Jade Rubick — Should QA exist
  20. On Commitments trade velocity for predictability: Sprint commitments trade velocity for predictability; high-trust teams usually do better with clear demo goals, honest best estimates, and continuous improvement. — Jade Rubick — Don’t make your engineering team commit

On Product and Strategy

  1. "As a consultant, I have a view across many companies. So I've seen a lot of product strategies. Most have been problematic." [12]
  2. "If your company's success depends on growing effectively, you need to get these things right. When a company grows quickly, it undergoes stress. The faster the growth, the more the stress."
  3. "Platform teams underestimate how much pain they cause when they deprecate their offerings. You should make deprecation rare."
  4. "It's inevitable that your team will need things from other teams. This is especially common in product engineering."
  5. "Software often feels like a house of cards, where it is surprising that anything ever works at all." [9]
  6. "If you are in a situation where the way the organization is structured does not fit what you need to drive some outcomes a task force is something you can turn to." [2]
  7. "A task force is basically like a temporary team that is either full-time or part-time that works against a particular problem." [2]
  8. "Communication delays overwhelm everything else i think that's actually really true." [2]
  9. "The setup of a task force is really important you don't want people to think it's a waste of time you need people to really buy into it it needs to feel important." [2]
  10. "Be careful not to overuse task forces they shouldn't have happening all the time. and if they are happening all the time that is probably a sign that your organization actually isn't very well structured." [2]
  11. On Measure value delivered over time: Measure engineering by value delivered over time rather than activity; ValueSum makes this concrete by weighting each delivered item by how valuable the work was. — Jade Rubick — Yes you can measure engineering
  12. On Product and Strategy: "ValueSum incentivizes validating ideas early. Why? You don’t want to invest a lot in something that isn’t valuable." — Engineering Leadership
  13. On Protect Horizon 3 from optimization: Protect risky Horizon 3 exploration from the optimization processes governing the core business, or it will always lose to more certain near-term work. — Jade Rubick — Adding innovation labs
  14. On Labs should scout and reject ideas: An innovation lab should scout uncertain terrain and reject merely good ideas with evidence; it should not become an alternate engineering team for urgent delivery. — Jade Rubick — Adding innovation labs
  15. On Agree on tradeoffs before deciding: For hard decisions, generate at least three approaches, agree on their tradeoffs, and then identify who should make the decision. — Jade Rubick — First agree on the tradeoffs
  16. On Strategy should make explicit choices: A useful strategy makes uncomfortable choices and clearly describes the gap between today’s state and the intended future; otherwise it is only a set of goals. — Jade Rubick — Some shoulds for strategy

On Growth and Scaling

  1. "When looking at a problem... Identify the largest driver to the problem. This is the 'input'. There can be multiple inputs, but try to look for the largest ones." [7]
  2. "I usually look for two types of solutions: (A) a solution that fixes it forever, and (B) a solution that merely gets you to a situation where things are always getting a little better." [7]
  3. "If it's always getting a little better, you pretty much don't have to worry about it. But if the gap between these two types of solutions isn't major, you might want to bite the bullet and solve it for good." [7]
  4. "Make it a business decision: 'do we want to accept the security risk for this until a better, more scalable version of my team is in place, or do we want to increase the headcount by X amount?' This becomes a tradeoff decision." [7]
  5. "When people say 'I intend to do X,' it does a number of things. one it helps people know what's going on so that you can coordinate with that person two it gives people a chance to intervene if there would be bad consequences. three there's a default to action instead of deadlock." [4]
  6. On Verification bottlenecks: "Engineering teams need to be thinking about how they can get out of verifying every line of code, because otherwise they're going to be completely buried in that and will absolutely be the bottleneck." — Aviator Podcast
  7. On Maintenance costs: The increasing volume of AI-generated code will cause significant problems for organizations if they do not reinvest their productivity gains into maintaining high code quality. — Aviator Podcast
  8. On Shipping untested commits: Engineering teams should incrementally build trust in their automated guardrails by setting a goal to ship a small percentage of commits to production without human verification. — Aviator Podcast
  9. On Growth and Scaling: "The complexity in organizations explodes with each additional layer of management." — Engineering Leadership
  10. On Growth and Scaling: Keep the span of control small when you need innovation, but expand it when scaling for efficiency. — Engineering Leadership
  11. On Growth and Scaling: The use of AI within organizations should center on lowering communication burdens and enhancing context rather than just removing management layers. — Engineering Leadership
  12. On Create structural bandwidth in thrash mode: Escape thrash mode by creating structural bandwidth: delegate, track fewer things, reset expectations, and redefine oversized work into smaller versions. — Jade Rubick — Getting out of thrash mode
  13. On Dependencies are structural problems: Cross-team dependencies are structural problems; heroics, heavier tracking, and more process cannot solve them consistently, so change team boundaries, scope, or engagement models. — Jade Rubick — Reducing dependencies
  14. On Piles reveal the constraint: Backlogs, unmerged work, QA queues, and other piles reveal the real constraint; faster AI coding can simply move the bottleneck elsewhere. — Jade Rubick — Piles point out your problems

Learn more:

  1. Jade Rubick
  2. Jade Rubick on task forces: a leadership guide to solving complex problems - YouTube
  3. Everyone lies to leaders - Jade Rubick
  4. Jade Rubick on being a bottleneck - YouTube
  5. Blog home - Jade Rubick
  6. Jade Rubick on reflecting power - YouTube
  7. How to develop a sixth sense for the long-term - Jade Rubick
  8. Wonderful hiring practices that for some reason aren't more common - Jade Rubick
  9. Jade Rubick on preventing incidents - YouTube
  10. Tiny Thursdays - Jade Rubick
  11. Jade Rubick on Tiny Thursdays - YouTube
  12. Jade Rubick - Medium