What I’ve been reading

I’ve never been into audiobooks, but I’ve taken up listening to them while exercising. I like it and feel better about it than listening to yet another podcast about Apple products.

Acceptance is not agreement

“It’ll be a disaster,” Marie says. Her eyes narrow, and she raps the table. “We don’t have the people and we’ve never used that stack in production.”

Devon, who’s been silent for the entire team meeting, nods, just barely.

Angela’s heart rate spikes. Yesterday the company’s biggest customer asked—demanded really—a new feature nowhere on the roadmap with hairy technical implications. Angela, the team’s tech lead, immediately sprung into action, whiteboarded with other tech leads and senior engineers on her team and across the company, and even endured an interminable one-hour phone call with that one sales guy she can’t stand. Nobody likes the situation, but Angela is proud of the plan she worked hard to put together. It’s a good plan.

And now this.

The hairs on the back of Angela’s neck prick up. Marie’s only been on the team for what, a month? She takes a breath.

“You’re wrong.”

Disagreement is inevitable on any team: whenever two or more humans come together, they bring differing knowledge, context, and motivations. This is healthy, but that doesn’t prevent the words “you’re wrong” from physically wrenching you into fight-or-flight.

Reacting to that feeling, digging in, and aggressively arguing your case is almost always counterproductive. Instead, disagreement is an opportunity to learn something, and maybe counterintuitively, build a stronger relationship by grappling honestly with another person’s perspective. All of this starts with being willing to recreate and acknowledge the other person and accept what they are saying without resistance, even if—especially if—you just know they are wrong.

Acceptance is not agreement: You can fully accept what someone is saying and still wholly disagree with it. You can acknowledge that understanding without looking weak, giving in, or committing to any action you don’t want to. Showing acceptance in the face of disagreement is an act of kindness, it builds knowledge, and it increases your influence and ability to drive agreement.

If you’re doing your job as an engineering leader, you should face disagreement all the time. You should encourage it! Being able to listen and explain your position without disempowering is a critical behavior of a leader.

Acceptance is a kindness

“It all starts with the universally applicable premise that people want to be understood and accepted. Listening is the cheapest, yet most effective concession we can make to get there.” - Chris Voss, Never Split the Difference

Actively listening to someone and accepting what they are saying is kind. Just think of how agonizing it can feel to be misunderstood, alone, or that no one listens when you talk. Lifting this burden from someone is a gift.

The key is to truly listen, don’t just hear. Don’t just shut up long enough to let the other person talk, nodding along until you get your turn. Don’t just murmur empty sounds of sympathy. That doesn’t accomplish anything. You should tune into and try to grasp their underlying ideas, feelings, and motivations. If done well, you can start to see what’s underneath the surface-level facts.

You may have to ask direct clarifying questions. That can feel uncomfortable and weird:

  • “It sounds like you are angry about this.”
  • “It sounds like you think I didn’t consider the team’s thoughts about this.”
  • “What I’m hearing is that you’re fine about this decision, but from your body language, it looks like you have doubts.”

This is hard work! And it can feel downright impossible if your adrenaline is pumping because you disagree about something that matters. In Crucial Conversations, the authors refer to this as “exploring others’ paths.” They recommend focusing intently on your sense of curiosity about the mystery of the other person:

To keep ourselves from feeling nervous while exploring others’ paths—no matter how different or wrong they seem—remember we’re trying to understand their point of view, not necessarily agree with it or support it. Understanding doesn’t equate with agreement. Sensitivity does equate to acquiescence. … There will be plenty of time later for us to share our path as well. For now, we’re merely trying to get at what others think in order to understand why they’re feeling the way they’re feeling and doing what they’re doing.

Once you think you understand what a person is saying, summarize it back to them in your own words to confirm. If you find this a struggle, have a go-to phrase you can use. For example: “Let me see if I follow what you’re saying. What this looks like from your point of view is…”

Repeat until you get it right. And thank them.

Note that nothing here involves apologizing, agreeing with them, or saying that you are wrong.

Acceptance can build knowledge

Beliefs are hypotheses to be tested, not treasures to be guarded. - Philip Tetlock

If you succeed at grappling with someone’s perspective, a magical thing may happen: you may learn where you are mistaken.

It may be flaws in your reasoning. Or facts that were hidden from you. Or maybe that you’re just plain wrong. If you can manage to listen in this way, you’ll invariably learn something. People bring different facts to the table because they know different things, have talked to different people, and spend their time thinking about things that you don’t. It’s foolish to ignore that! It’s not your job to have all the answers.

Acceptance can build consensus

One of the best ways to persuade others is with your ears—by listening to them. - Dean Rusk

The quickest way to ensure someone never changes their mind is to try to ram something down their throat. Just think about how you would feel! However, by showing that you are genuinely open to what they are saying, you signal that you yourself are open to change, and therefore, make the other person feel a little bit safer about being open to change themselves. People will not listen unless they feel listened to. Consensus is not achieved by steamrolling or by downplaying someone else’s opinions.

From Getting to Yes: Negotiating Agreement Without Giving In:

Unless you acknowledge what they are saying and demonstrate that you understand them, they may believe you have not heard them. When you then try to explain a different point of view, they will suppose that you still have not grasped what they mean. They will say to themselves, “I told him my view, but now he’s saying something different, so he must not have understood it.” Then instead of listening to your point, they will be considering how to make their argument in a new way so that this time maybe you will fathom it.

Reaching consensus is not about rationally weighing objective facts. It is a narrative. Each person needs to be able to tell themselves a story in which they are the protagonist who is respected, heard, and acts with autonomy. When someone makes an argument, they are (1) presenting their facts for judgment, but more importantly, they are (2) putting up their story, and themselves, for validation. Acceptance—even without agreement—is the first step towards consensus.

As a leader and a human, be committed to getting to the right outcome, but not invested in personally being right. You don’t look like less of a leader by listening intently and being open to change. People respect the ability to accept criticism with grace more than you might think. It’s hard! People get that.

Don’t let your fear of giving in dissuade you from engaging with and understanding someone else’s perspective. You’ll usually learn something. You can’t make everyone happy all of the time, but if you work at it, you can make everyone feel respected and heard.

Listen

Angela listens. She asks questions. She repeats and summarizes. She bites her lip.

“I just don’t like being jerked around,” Marie says. She looks straight at Angela, then exhales. “I think if we get some support from an SRE up front, this can work.”

Angela nods. “I like that. I’ll see what we can do.”

What I’ve been reading

  • Kim Scott, Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity. This is a fantastic book. I resisted reading it for a long time because I associated “radical candor” with Silicon Valley bros patting themselves on the back for being a jerk. It’s not that, at all. This has reframed my approach to communication in the workplace. Recommended.
  • Roger Lowenstein, Buffett: The Making of an American Capitalist. A straightforward narrative read, and a gentle introduction to the idea of value investing and Buffett’s general approach. Buffett has had a more complicated personal life than I realized. I found the author overly credulous.
  • Alison Weir, Henry VIII: The King and His Court. Heavy on inconsequential details; light on context, analysis, and narrative.
  • Ken Kocienda, Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs. An easy narrative read by a software engineer who created the original touchscreen keyboard on the iPhone. I found it insightful and interesting. My biggest takeaway was the critical importance in product development of a rapid feedback loop of working software. As the author is careful to state, the specifics aren’t necessarily applicable outside of the context of mid-2000s Apple. It’s written for a general audience, so software engineers will find some parts tedious.

Elsewhere on the web

Statistics, lies and the virus: five lessons from a pandemic.

Practical Management Expectations (and Mandates). The VPE of Spotify’s expectations for managers.

Being the grumpy engineer is harmful to your career. Avoid falling into the feasibility trap.

Camille Fournier on Effectively Managing Internal Platform Teams. “Great platform teams can tell a story about what they have built, what they are building, and why these products make the overall engineering team more effective.”

Elsewhere on the web

To lead, you have to follow. “I think this is the most important lesson I’ve learned over the past few years: the most effective leaders spend more time following than they do leading. This idea also comes up in the idea of the “first follower creates a leader”, but effective leaders don’t split the world into a leader and follower dichotomy, rather they move in and out of leadership and follower roles with the folks around them.”

Implementing Shape Up.

The Paradox of Autonomy and Recognition. “We work tirelessly, doing our very best to get things done on time, but somehow we get passed over—in favor of someone else whom you honestly believe didn’t contribute nearly as much as you did. What happened to meritocracy and being recognized for your work?”

The Startling Convexity of Expertise. “There are studies showing that productivity per hour drops after forty hours per week, and turns negative at higher levels — but these are studies of dangerous factory jobs, or monotonous call-center work. And I don’t doubt it. If I spent a hundred hours a week on the assembly line at a munitions factory, I’d probably end up dropping a missile on my foot or something, which would do a number on my productivity.”

Relentlessly intentional: Practices for effective virtual meetings

Drawing of Zoom window

Holding a successful virtual meeting can be challenging, especially when the goal is to collaborate or brainstorm. It’s hard! The good news is that if you approach it intentionally and do the work, you can do it successfully.

The dirty secret is that many in-person meetings don’t work particularly well, either. People don’t like meetings for a reason. Discussions are undirected, topics are missed, decisions aren’t captured, time is wasted. When meeting in person, it’s easy to coast and let the high-bandwidth of face-to-face communication compensate for deficient meeting leadership. And it’s often easy to feel like the meeting accomplished something, when in reality, it didn’t.

The key to holding a successful virtual meeting is to be relentlessly intentional. If you call a meeting, you have a responsibility to the people you ask to attend to not waste their time.

The following is a toolbox of practices you can choose from to maximize your chance for success. Let’s break them down to before, during, and after the meeting.

Before the meeting

The short version: Accomplish as much of the meeting as you can before the meeting. Specifically, I recommend:

1. Ask: Does this meeting need to exist?

If it’s a status meeting, can it be handled through Slack updates? An email? Can it be handled by collaboratively updating a confluence page? Instead of a live demo, can the demo be prerecorded and dropped in the status page?

Put another way, can this meeting topic be better handled through asynchronous communication?

Don’t be afraid to cancel a standing meeting if there’s nothing to talk about.

2. Pre-publish an agenda, and ask attendees to contribute

An agenda is essential for any meeting, but especially crucial for virtual meetings. Write a solid agenda and publish it in advance (we use Confluence). Define the purpose of the meeting. List specific items for discussion. Send the agenda to meeting participants, and ask them to write their updates or agenda items in the meeting agenda before the meeting.

This does a few things. It gives structure to the meeting, lets people know what to expect when they arrive, and helps keep discussion usefully on topic during the meeting.

And also, critically, writing a concrete agenda requires you to clearly define what the meeting is about, not least of all to yourself. What problem are we trying to solve? What background information do we already have that can be shared ahead of time? Spelling all this out forces you to think more rigorously about both the problem and how best to discuss it.

Your goal is to reduce the number of words that need to be spoken aloud in the meeting itself.

Examples

For example, I hold a weekly coordination meeting for our engineering teams. Team leads write their updates ahead of time in a shared meeting notes page. In the meeting, people read the notes silently. (Reading is faster than speaking!) Discussion launches off of that.

This sounds strange, and feels strange the first time you do it, but it is recommended by Edward Tufte and practiced at Amazon and Microsoft. From What You Do Is Who You Are by Ben Horowitz:

To convene a meeting at Amazon, you must prepare a short written document explaining the issues to be discussed and your position on them. When the meeting begins everyone silently reads the document. Then the discussion starts, with everyone up to speed on a shared set of background information.

If you have to talk about something complicated, you want to load the data into people’s brains as quickly as possible so you can have an intelligent, facts-based conversation about the business decision you’re trying to make.

This works for collaborative meetings as well. For example, we hold a recurring Incident Response Program meeting. The goal is to learn from recent customer-impacting incidents through a discussion centered around pre-written, detailed incident reports. Each incident report is written in Confluence and collaborated on asynchronously before the meeting through editing and commenting on the page. The incident reports are detailed and complex. Writing (and reading) the IRs before the meeting saves time, provides shared context, and enables a focused, targeted discussion about big-picture issues, instead of wasting valuable time recalling and reconstructing a detailed timeline of events necessary for the real discussion.

3. Create a meeting-specific Slack channel for standing meetings

A meeting Slack channel is useful for notifying attendees of new agendas, raising pre-meeting questions and discussions about meeting topics, and as a launching point for post-meeting parking-lot item breakout discussions. It can facilitate valuable side conversations.

Running the meeting

First, start on time, every time. When you call a meeting, you have an obligation to everyone involved to use their time wisely and frugally. Starting on time fulfills that obligation and sets the tone for the rest of the meeting.

One of the hardest things about a virtual meeting is that video conferencing adds friction to natural conversation. In Zoom, everyone is a tiny box, video and audio can be laggy and low resolution, and audio can cut out if too many people speak at once. These tiny boxes share screen real estate with the concentrated distraction power of the internet, or at the very least, the work the attendees were engaged in 10 seconds before the meeting started.

Humans are social creatures who find satisfaction in being together in a shared space. A virtual meeting just doesn’t feel as good. Even if it accomplishes its goal, it can feel unsatisfying.

These three techniques can help:

1. Act proactively and intentionally to facilitate conversation

When running a virtual meeting, it is incumbent on you to actively facilitate a productive discussion. It is your meeting—drive it. Don’t just sit back and passively allow things to happen.

  • Ask people to turn on their video. If someone’s sound is quiet or breaking up, inform them. Spend a little time improving your video-conferencing setup.
  • Clearly articulate the goal of the meeting and its agenda.
  • Purposely move through the agenda. Redirect tangents back to the topic at hand.
  • Ask clear, meaningful questions to guide the conversation.
  • When someone yields in a conversation “collision,” make sure to circle back to the yielder.
  • Aggressively move side discussions to the parking lot. Assign a specific owner for each item to coordinate a breakout discussion in the meeting’s Slack channel.
  • Also, be energetic! Sitting in front of tiny boxes on a computer screen is not as engaging as sitting in the same space as other humans.

2. Use simultaneous editing

Instead of brainstorming verbally in an informal back-and-forth, consider brainstorming on a Google Doc or Confluence page using simultaneous editing.

One type of meeting where this has proven powerful are retrospectives. In a virtual retrospective, people write in their ideas for what to start, stop, and continue directly on the page, at the same time. Each participant can see what the others have written and vote on it.

When we conducted retrospectives in person, people would write their ideas for stop, start, and continue on sticky notes. The sticky notes then had to be collected, collated, and counted. Simultaneously editing a shared document makes this easier. We have found that virtual retrospectives are more generative, more focused, and take less time than in-person retrospectives.

3. Take notes. Capture all decisions. Close strong.

Take detailed notes. It’s easier to be distracted in a virtual meeting, so it is crucial to capture everything of importance. A good technique here can be to leave the page open on a shared screen and invite other people to contribute.

This is particularly useful for capturing decisions and action items. Capturing decisions—clearly marked with background reasoning—can save literally hours of rehashing the same conversation months later. Tasks should be assigned to a specific person.

Close the meeting strong, with energy. Don’t just let it putter out. Recap any significant decisions and action items. Thank people for coming.

Again, virtual meetings naturally tend towards low energy. Closing strong is an act of leadership that can help people feel more excited about the project, and more closure at the outcome of the discussion. People remember how something ends much more clearly than the middle, so a strong close influences how people feel about the entire meeting, and therefore also the substance of what was discussed. Yes, all of this is about feelings. But humans are emotional creatures. Motivating people to their best work is leadership, and leadership is precisely the responsibility you signed up for when you called people together for a meeting.

After the meeting

The effectiveness of a meeting is measured by its output. A meeting’s output is its real-world consequences—things that happen that would have not otherwise happened in the absence of the meeting.

All of this occurs after the meeting. That means that post-meeting follow-up is a critical, first-class component of running a successful meeting. Make sure to:

1. Coordinate breakout discussions

A lot of the value of an in-person meeting comes from the informal breakout discussions after the meeting ends, as people file out the door. This is not something that happens in virtual meetings.

Actively coordinate breakout discussions (such as parking lot items). It is useful to do this in a public Slack channel so the conversations are visible to everyone. Anyone can join if they are interested or have something valuable to contribute.

2. Publish the meeting notes

After you have finished updating the meeting notes and capturing action items and decisions, post it in a Slack channel, or if there isn’t one, email meeting participants and relevant stakeholders.

If this is a recurring meeting, have a standing agenda item to follow up weekly on action items. If it’s not, the responsibility to follow up falls on you.

Relentlessly intentional

Holding a successful virtual meeting is harder than holding a successful in-person meeting. Things that “just happen” in person have to be made to happen by you. You need to communicate asynchronously, push as much of the meeting before the meeting, actively facilitate conversation, and follow up to make sure things happen.

Elsewhere on the web

Action Produces Information and Decisiveness is Just as Important as Deliberation. “In theory, the most difficult challenge in decision making is making the right decision. In practice, I’ve found that the most difficult challenge in decision making is executing a decision you do not want to do.”

Why Is This Idiot Running My Engineering Org? “When people begin to take on leadership roles eventually they have to decide how they are going to handle fear. When you are the leader, you are the person who is held accountable for failure. The higher up you go, the more you are accountable for and the less you have control over it. Trust in you team is important, but your perception and acceptance of risk even more so. Leaders with a low tolerance for risk do not become leaders with a high tolerance for risk if you change their employees looking for trustworthy ones. Everybody wants to have this implicit, instinctual, don’t-need-to-think-about-it-and-never-doubt-it-for-a-second trust. That’s the gold standard. But most relationships of trust are formed because you just choose to set aside your doubts and trust, not because you have these great reservoirs of faith.”

Remote teams and the half-life of social capital. “We all know that being nice to each other is better than being mean. It seems self-evident. So it’s reasonable to wonder: Why bother thinking about this at all? Is it all mere academic over-thinking?”

Magnitudes of exploration. “Fewer technologies support deeper investment in each, and reduce time spent on cross-technology integration. Narrow standards simplify the process of writing great documentation, running effective training, providing excellent tooling, etc.”

Making the decision right

Project Orange Traffic Cone versus Project Halibut

One idea I’ve found surprisingly useful is summed up in a single sentence: While it is important to make the right decision, it is more important to do the work to make the decision right.

This idea puts the focus on implementation as the fulcrum of a successful decision. It shows why quickly making and acting upon a good-enough decision can be better than spending a long time analyzing and searching for the perfect decision. And it shows why Agile’s iterative approach to minimizing decision size can be so effective.

I’ll discuss this by way of engineering management, but the principles apply widely. I won’t discuss the process of reaching decisions, even though I believe that almost everyone can benefit from trying a more systematic and rigorous approach.

1. There are no “right” and “wrong” answers

When making a decision in a complex environment (i.e., the real world), there usually isn’t an objectively “correct” answer. This can be hard to accept: in school, we’re assigned math problems, and those problems have clear and correct answers, printed in the back of the book or marked up in red by a teacher.

Decisions in real life (mostly) aren’t like this, especially as you advance in your career and face decisions of greater importance and ambiguity. Which technology stack do you choose? Do you prioritize Project Orange Traffic Cone or Project Halibut? Do you stay at your current gig, or jump ship to a new one? Complex decisions like these rarely have unambiguous, objective, correct answers.

There are a few reasons for this. First, the consequences of a decision are sometimes known only much later. Even then, it may be impossible to evaluate it against the possible alternatives that were available at the time. And it can be hard even to know how to evaluate a decision, even in retrospect. Sometimes a decision was wrong from day one. But other times, a decision becomes wrong because of a change in circumstances.

Second, sometimes there isn’t a 100% right answer, only answers with mutually exclusive tradeoffs. (“Good, fast, cheap. Choose two.”)

Third, in almost any complex decision, the different people involved will bring different facts and judgments about relevance. Marketing can have very different ideas of what information matters in a product decision than engineering.

And fourth, there can be disagreement about what the desired high-level objective of the decision even is. For example, suppose you decide to work on Project Orange Traffic Cone over Project Halibut. That decision is intended to achieve a high-level goal: to deliver the product that will be the most profitable. Or perhaps the product that is most useful to customers. Or that best fits into the company’s higher-level strategy. Or something else. Different people judge success (or failure) differently, in sometimes mutually exclusive ways. You can work to achieve alignment on this, but people will often have criteria that are important to them, tied up in their own goals or the perceived impact on their relative status.

2. The output of a decision is its consequences

The purpose of a decision is to create consequences in the real world, so the best way to evaluate a decision’s effectiveness is through those consequences.

It’s useful to think of a decision as if it were a “black box”: input (a situation in the world and the people and processes involved in making a decision) flowing in, and the output (real-world consequences) flowing out:

A decision as a black box

This is what a decision looks like from the outside to someone uninvolved. How a decision is made—what happens in the box—is irrelevant to its observable consequences. For example, if you decide to hire someone for your team with great qualifications after a rigorous interview process, and then three months later, this person bails on you, that’s not a successful consequence. It is not a successful decision.

Yes, the decision-making process matters! But those processes have limitations, and what ultimately what matters are actual results. Customers don’t care about your decision-making process. Decisions are a means to an end, and that end is real-world consequences.

3. At the moment you make a decision, it is impossible to know if it is good or bad

A decision is measured by its output (real-world consequences), not by a theoretical accounting of whether it is good or bad. So you can’t evaluate its quality until time has passed and those consequences are clear. Of course, in some situations, you may never know if the decision was the best choice out of the available options since you can’t run the counterfactual.

4. A decision itself changes nothing

A decision doesn’t have any observable output—real-world consequences—unless you act on it. Merely changing your mental state does not create consequences in the real world. The execution of the decision is part of the decision.

Chris Voss touches on this in Never Split the Difference while talking about negotiated agreements:

“Yes” is nothing without “How.” While an agreement is nice, a contract is better, and a signed check is best. You don’t get your profits with the agreement. They come upon implementation. Success isn’t the hostage-taker saying, “Yes, we have a deal”; success comes afterward, when the freed hostage says to your face, “Thank you.”

Let’s say you decide to buy a new car. Until you sit down, do research, visit dealerships, and finally write a check, what you have is an intention but not a decision. Considering the concrete implementation is a good way to clarify your decision-making: you can’t decide to buy a BMW if you don’t have the money and don’t qualify for a loan.

In the Effective Executive, Peter Drucker writes:

Converting the decision into action is the fourth major element in the decision process. While thinking through the boundary conditions is the most difficult step in decision-making, converting the decision into effective action is usually the most time-consuming one. Yet a decision will not become effective unless the action commitments have been built into the decision from the start.

In fact, no decision has been made unless carrying it out in specific steps has become someone’s work assignment and responsibility. Until then, there are only good intentions.

Converting a decision into action requires answering several distinct questions: Who has to know of this decision? What action has to be taken? Who is to take it? And what does the action have to be so that the people who have to do it can do it? The first and the last of these are too often overlooked—with dire results.

How many meetings have you been in with energetic discussion, everyone’s excited, decisions were made, and then … nothing happens? No one took responsibility for action items. No one followed up. In the end, all you had was good intentions.

5. You will spend more time living with the consequences of a decision than deciding the first place

This is the crux. You and the team decided to tackle Project Orange Traffic Cone. Even if you followed a rigorous process, thoroughly discussed the question with the team and with stakeholders to gain consensus—all things that take time—the development team will spend far longer implementing that decision (building Project Orange Traffic Cone) than the time it took to reach the original decision point. So how you act is as crucial to the outcome as the “rightness” of the decision itself.

So let’s talk about execution.

Execution is where you make the decision right

For example, let’s say you made the “wrong” decision and worked on the “wrong” project. Maybe Project Halibut theoretically had more financial upside than Project Orange Traffic Cone. So you blew it? Maybe. But there’s still a high chance that delivering Project Orange Traffic Cone quickly, nailing the implementation, and listening to user feedback and iterating is more profitable than a late and haphazard implementation of Project Halibut. Skill and rigor and energy of execution can sometimes—although not always—make up for a suboptimal initial decision.

The output of a decision is its real-world consequences, and execution is the forge where those consequences are constructed. Execution is where a decision becomes real, and where operational excellence, skill at craft, rigorous project management practices, communicating an elevating purpose, and even the psychological safety and intrinsic motivation of a team become determining factors. It’s time to do the work.

Feedback and iteration are part of execution

Once a decision has been made and committed to, it is effectively a sunk cost. It is done. But… And here is the critical point—that does not mean marching blindly forward. Listening to feedback about the decision, observing the real world, and adapting are all critical to implementing the decision.

Peter Drucker, again in The Effective Executive:

Finally, a feedback has to be built into the decision to provide a continuous testing, against actual events, of the expectations that underlie the decision. … Even the best decision has a high probability of being wrong. Even the most effective one eventually becomes obsolete.

To go and look for oneself is also the best, if not the only, way to test whether the assumptions on which a decision had been made are still valid or whether they are becoming obsolete and need to be thought through again. And one always has to expect the assumptions to become obsolete sooner or later. Reality never stands still very long. Failure to go out and look is the typical reason for persisting in a course of action long after it has ceased to be appropriate or even rational.

Another way to think of this is that action generates new information, which then allows you to make better decisions. The information you create by acting is often very high quality and more valuable than insight generated through passive analysis. A trite example is that you can learn faster about product/market fit by launching an MVP and getting real customers to use it than you can by doing a lengthy abstract market analysis.

Once you are acting, you are generating new information. Even if your initial decision is wrong, you can almost by definition make a better second (or third, or fourth) decision because you now have more high-quality information and real-world feedback to work with.

Work to minimize decision size: Decision making and Agile

Agile as a methodology and philosophy is focused on compensating for the impossibility of humans making correct, up-front decisions in the face of complexity. Instead, Agile encourages making a series of small decisions, acting on those decisions, and continually adapting and iterating based on real-world feedback from real users. It recognizes that shipping software creates new information about what software you should be building. If you can minimize your time to ship, you can get that information faster.

In other words, you should minimize decision size: avoid big decisions in favor of a sequence of smaller decisions. This is captured in the first three principles of the Agile Manifesto:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

In scrum, a team works in two-week sprints. At the beginning of a sprint, the team decides on a high-level outcome and selects the work to achieve it. After a sprint, the team holds a retrospective to reflect on how they worked and then plans the next sprint—deciding the subsequent outcome to achieve. Structured reflection and iteration are built directly into the execution.

Another feature of the two-week sprint is that it is a forcing function on decisions and execution. It’s hard to ship software when you can always add another feature, fix another bug, polish things a bit more. When you have a sprint deadline, you must make decisions about tradeoffs quickly, which allows you to generate new information through acting.

Conclusion

Deciding is inseparable from doing. And ultimately, it is the doing that makes the difference.

The purpose of making a decision is to change something in the world and make something happen that would have not otherwise happened if you did not act. It is one thing to make up your mind that something should change—problems are not hard to find—and another to do the prolonged hard work of building something in the real world. It’s one thing to have an intention and quite another to get out of your chair and act.

The world doesn’t need more good intentions; it needs more useful actions. It needs people to build, execute, and to create the future. It needs people to do the unglamorous plain old hard work of taking the mind-stuff of a decision and making it real. It needs people to act in small ways with integrity every day. It needs people to make decisions right.

Orange Traffic Cones

What I’ve been reading

  • Charles Mann, The Wizard and the Prophet: Two Remarkable Scientists and Their Dueling Visions to Shape Tomorrow’s World. Mann is the author of two other great history books, 1491 and 1493. One of the things that struck me was the sheer amount of grueling, monotonous, detail-intensive hard work that Norman Borlaug did to cultivate his new dwarf wheat variety that has kept literally hundreds of millions of people from starving. He should have failed, and if he knew more about the field he might never had tried, and in fact he had to hide much of his work from his supervisors. So much of what we take for granted in the modern world is hard earned.
  • Ryan Singer, Shape up: Stop Running in Circles and Ship Work that Matters. I found this book fascinating as kind of an alternate-universe Agile. So much of Agile adoption in the wild is cargo culting, so seeing many of the same problems solved with a different twist with different language is valuable to contemplate, even if you do not explicitly adopt anything in the book.
  • Chris Voss and Tahl Raz, Never Split the Difference. Applicable to more than just negotiation.

‘No’ is a reaffirmation of autonomy

“No” is the start of the negotiation, not the end of it. We’ve been conditioned to fear the word “No.” But it is a statement of perception far more often than of fact. It seldom means, “I have considered all the facts and made a rational choice.” Instead, “No” is often a decision, frequently temporary, to maintain the status quo. Change is scary, and “No” provides a little protection from that scariness.”

“So let’s undress “No.” It’s a reaffirmation of autonomy. It is not a use or abuse of power; it is not an act of rejection; it is not a manifestation of stubbornness; it is not the end of the negotiation.

In fact, “No” often opens the discussion up. The sooner you say “No,” the sooner you’re willing to see options and opportunities that you were blind to previously. Saying “No” often spurs people to action because they feel they’ve protected themselves and now see an opportunity slipping away.”

Today, I coach my students to learn to see “No” for what it is. Rather than harming them or those they negotiate with, “No” protects and benefits all parties in an exchange. “No” creates safety, security, and the feeling of control. It’s a requirement to implementable success. It’s a pause, a nudge, and a chance for the speaker to articulate what they do want.”

Chris Voss, Never Split the Difference

When beginning a difficult conversation with someone, it’s easy to take someone’s initial reaction as their final decision. This has been a useful reminder to me that reaching common ground is possible in more situations than I think.

This is a useful book. I will have more to say about it.