tl;dr:“Imagine a simple scenario. Your manager is proposing changes to your roadmap. Those changes would negate months of work by your team. You lead the team and don’t agree with the new direction. Following a robust discussion your manager makes the change over your objections. How do you proceed?”
tl;dr:“Imagine a simple scenario. Your manager is proposing changes to your roadmap. Those changes would negate months of work by your team. You lead the team and don’t agree with the new direction. Following a robust discussion your manager makes the change over your objections. How do you proceed?”
tl;dr:“There are lots of teams tasked with risk reduction: legal, security, and finance just to name a few. These teams generally err on the side of moving more slowly or saying no entirely. Other teams like sales, engineering, and design are generally in roles that involve risk creation. They tend to be inclined to say yes to new ideas in the pursuit of new forms of value.” This organizational phenomenon is called Stars and Guardians, and Andrew discusses how to lead with both.
tl;dr:“Failures happen. In engineering we often face a choice between trying to eliminate failures or making our systems handle them more gracefully. Both approaches are important but in my experience fault tolerance is the more valuable. The reason is simple: we can only eliminate failures we can imagine while fault tolerance adds some resilience to failures we could not imagine. I have found the same to be true for groups of people.” Andrew discusses how to implement this in management.
tl;dr:Andrew discusses the superpower of being plainspoken. “Our desire to maintain harmony can cause us to be indirect about uncomfortable truths. Our desire to influence can cause us to pre-emptively address every arcane objection. Our desire to impress can cause us to use more language than necessary. And the expectations we have internalized about corporate communication often cause us to write in a way we never would to our friends.”
tl;dr:From the CTO at Meta: “One of the most common anti-patterns I see that can create conflict in an otherwise collaborative environment is people asking for permission instead of advice. This is such an insidious practice that it not only sounds reasonable, it actually sounds like the right thing to do: “Hey, I was thinking about doing X, would you be on board with that?”" Andrew argues that the problem with asking for permission is that you’re implicitly asking someone else to take some responsibility for your decision. Asking for advice creates advocates for your idea but doesn't saddle them with responsibility.
tl;dr:CTO at Meta, discusses his approach to managing communication with his teams... “For those who are curious, my system is Inbox Ten. That means I aim to end every day with fewer than ten emails in my inbox. I also have fewer than ten open chat threads across all interfaces. I’ve also read all relevant notifications in internal tools, read all relevant posts in internal groups I care about, and started rough drafts of any relevant proactive communications I intend to produce.”
tl;dr:Andrew, the CTO at Meta, discusses how “your greatest strengths almost certainly dictate your greatest weaknesses... I have always considered communication a strength of mine. I enjoy speaking and writing, and do so often. I am forceful in championing my point of view. It took years to realize that I was “communicating” so much that I wasn’t listening. I was either drowning out my peers or waiting for my turn to speak.” Andrew discusses how this was a pivotal moment of growth for him.
tl;dr:Andrew, CTO at Meta, discusses the importance of storytelling at work: “Too often we present our work as a series of facts. The sad truth is that most humans are bad at remembering facts. When our audience is in a related conversation days later the data we shared isn’t likely to be top of mind anymore. Our impact remains localized. But humans are amazing at remembering stories. We are suckers for anything with narrative context, dramatic tension, and a satisfying or poignant resolution.”
tl;dr:The environment you are working in has a rate of change (entropy) e.g. competitors, regulators, consumer behavior. The relationship between this rate and the unit of work you undertaking is critical to understand: (1) If the unit of work is bigger than the rate of change, then you will fall behind. (2) If your unit of work is smaller than the rate of change you are likely driving change for others. Sometimes you have an irreducibly large bit of work that doesn’t fit inside the entropy window e.g. a re-architecture. The likely outcome is that midway through the very expensive program you’ll find yourself having to start it over because the environment you are building for continues to evolve.