Bob Lail

Most Of What I’ve Learned, in Five Verbs

2019-09-15T00:00:00+00:00

This year I started a new job. I wanted to approach my craft with a beginner’s mind, so I purposefully set aside the processes, tools, and language I knew so well. These were things I’d helped to evolve through years of iteration, and after setting them aside, something unexpected happened. I started finding it difficult to access the lessons that led me to those solutions. Trying to recall and apply them felt like rummaging through a junk drawer. 😕 The lessons, apparently, were not organized and not handy.

I dumped out the junk drawer and arranged its contents different ways. Some lessons were patently similar. For example, Write small methods, Deploy in small batches, and Slice tasks vertically clustered around a theme of smallness. I wondered why. (Were there other clusters like that?)

I thought I was looking for principles (clusters around Why?) so, of each acquired habit, I asked Why do I do this? recursively. It wasn’t helpful. I “discovered” that I write small methods to produce readable and malleable code — and that I value readability and malleability because they help a team deliver value through time. In fact, that objective — helping a team deliver value through time — turned out to be the ultimate Why? of every habit in my drawer!

Eventually I noticed that Write small methods and Slice tasks vertically are more similar in their How? than their Why? When I started asking How? of my acquired habits, I found clusters, immediately compelling clusters, around verbs. They were simple to understand but hard to master, few in number, and the lessons around them crossed contexts and scales.

These are the verbs that emerged from my experience so far:

Explaining Why
Slicing
Holding your Action
Automating
Failing Early

1. Explaining Why

Personal Rules

Pick intention-revealing names
Use commit messages to describe your goal
Why? is the most valuable documentation of any process
Why a customer requests a feature is more valuable than What they request ¹
(Indoctrinate in the Commander’s Intent) ²

The Goal

Explaining Why empowers your audience to change. It links your solution to the problem it solves. This de-risks change the way that unit tests do — by allowing future colleagues to check whether a new solution (process, UI, architecture, etc) also solves the original problem. And it invites change the way an expiration date does — by revealing the conditions under which the existing solution is no longer needed.

Neglecting to Explain Why hamstrings your future teammates. Faced with a change but unable to say why the current code, process, or roadmap exists, they must choose between caution and recklessness: either changing too slowly or taking preventable risks.

What to Practice

Dig for it. Why can be hard to write because it’s often, at least partially, implicit. A plan will seem sensible to us (or code smelly or a process natural) because of subconscious factors like our beliefs and habits — because of what we believe the problem and goal to be and because of what tradeoffs and judgments we are accustomed to making. In both cases, some of what we need to verbalize to Explain Why must be dredged up from nonverbal places.

The goal of writing code, commit messages, handbooks, design docs, and feature requests is not to lob information over a fence to a stranger but to come alongside a friend and give them a warm handoff. Explaining Why invites someone into your thought process and encourages them to see the problem, tradeoffs, and solution as you do. It is gentle, cordially persuasive writing.

2. Slicing

Personal Rules

Isolate responsibilities (in methods, objects, microservices)
Make commits atomic
Slice tasks vertically ³
Keep deploys small
(Break monolith organizations into small, autonomous teams) ⁴

The Goal

Slicing improves flow. It allows work to move through a system in smaller batches. (Picture the difference between an animation at 30fps and one at 5fps or between an hourglass filled with sand and another filled with gravel.) Slicing tasks lets you start delivering value sooner, be more transparent about your progress, and get blocked less often.

Complexity is also a batch:, a set of things that must be comprehended together. Slicing methods and objects until they have just one responsibility (and one level of abstraction) improves the flow of reading and makes maintenance easier.

Breaking down a complex thing into understandable chunks is essential for understanding, perhaps the essence of understanding. Bret Victor

What to Practice

Find the seams. The ideal batch size is one: one thought at a time, an atomic change, a single responsibility. These Batches of One are obvious after we slice but seldom before. Prior to slicing, we tend to find thoughts, responsibilities, and tasks tangled together, and their seams aren’t easy to see.

It’s possible to slice across seams. For example, we might slice a project into tasks that have to do with the same layer of the architecture:

Create all the models
Create all the controllers
Create all the views

Or we might break up a large Person model by extracting into modules:

All the methods that have to do with contact information
All the methods that have to do with employment
All the methods that have to do with posts and comments

These crosscuts aren’t Batches of One, however, because they aren’t independent of each other. The three tasks deliver no value until all of them are completed. And the three modules don’t reduce the complexity of Person at all; they just spread it across more files. Instead of achieving the benefits of Slicing, these examples introduce a new obstacle: they make it harder to see the true seams in the original project and model. To make progress in this situation, it’s often helpful to merge the bad slices and start fresh.

Good slices are independent of each other. To slice effectively, we learn to find seams that create standalone chunks of work or thought. Each task ships a sliver of value. Each commit could be deployed by itself. Each method or object owns a single tiny responsibility.

3. Holding your Action ⁵

Personal Rules

Write the simplest thing that could work, then refactor
Design from the outside in
Measure before you optimize
Don’t build a feature before it’s needed (i.e. Yagni)
Adjust roadmaps continually

The Goal

Holding your action reduces waste. Hitting pause on work that isn’t needed yet avoids wasted effort in the form of overproduction, overthinking, and overspecifying. Wasted effort is plainly bad, but the unneeded features and decisions themselves can be worse. While seeming harmless (valuable even), maintaining, revisiting, and following-through on them ties the team up in pointless work.

There is surely nothing quite so useless as doing with great efficiency what should not be done at all. Peter Drucker

What to Practice

Apply the brakes. In the midst of overproducing, overthinking, or overspecifying, our activity will not feel like waste. (It isn’t yet! We will only know that in hindsight.) Instead, we will be caught up in the momentum of excitement, anxiety, or inevitability. An engineer will be eager to solve an edge case that’s just occurred to her. A project sponsor will be anxious to seize a possible opportunity. A team will feel obligated to fulfill all the expectations fueled by their roadmap.

To check a momentum-fueled goose chase, get in the habit of taking a few seconds to ask, “Do I need to build/decide/answer this right now?” If your answer is “no,” then ask two followup questions: “When the need arises, will I realize it?” and “When the need arises, will I be able to build/decide/answer this then?” If your answer to either followup question is “no,” is there a way to adjust your process that will switch it to “yes”?

What is the future cost of doing nothing now? Sandi Metz

4. Automating

Personal Rules

Handle alerts once
Create jigs ⁶
Automate deploys
Use information-radiators
(Don’t make a hundred decisions when one will do) ⁷

The Goal

Automating builds momentum. In the book Good to Great, Jim Collins evoked the image of a giant, heavy flywheel. You push it. It turns slowly at first, but as it builds momentum it moves faster and faster. With each turn, you apply the same effort as before, but the flywheel’s momentum works for you and your effort is magnified. The flywheel accelerates because, with each turn, you compound the kinetic energy you have transferred to it. In a similar way, teams accelerate when they offload work to their environment: to toolchains, processes, cadences, simple rules, dashboards, and other automata.

I’ve known people who have not mastered their tools who are good programmers, but not a tool master who remained a mediocre programmer. Kent Beck

What to Practice

Notice what pulls you away from your essential work. The flywheel can build momentum in negative directions as easily as it can in positive directions. Automations can create busywork for humans. They can entrench work that wasn’t necessary in the first place, masking an inefficient process. So first focus on what your essential work is. Then be rigorous about not doing what you don’t need to do.

Your essential work may differ from what you do day-to-day. Your daily tasks might include a host of helpful activities that can be offloaded to the environment. By doing these, though, you spend less time doing the hard (but critical) work of empathizing with your customers, learning, brainstorming, analyzing, recognizing patterns, and articulating your intentions. Your essential work is what can’t be offloaded to the environment, not just what isn’t obvious to offload.

Notice friction, repetitive tasks, non-value-add work, checklists (a regular task that takes more than one step), rework (like when you do a task infrequently but have to figure it out each time), waiting (like for a script to finish), extra context-switches (like if you’re waiting for a script to finish and it takes just long enough for you to check your email). These are jobs that can be offloaded to your environment — to scripts, chat bots, policies, information radiators, and all sorts of nonhuman collaborators.

Design your environment so that it nudges and motivates you to do the stuff you believe you should be doing. Ryan McGreal

5. Failing Early

Personal Rules

Write unit tests
Raise exceptions at root causes not symptoms
Do the riskiest task first
Ship the smallest thing that will let you start testing assumptions (e.g. MVP)

The Goal

Failing Early reduces risk. It converts assumptions into hypotheses and then tests them. In so doing, it minimizes the downsides of failure (its impact on customers, the time it takes to correct it) by reducing the distance between a failure and the first sign of it. An assumption about user behavior that is falsified sooner costs less in wasted effort. Similarly, an exception raised nearer its root cause is easier to troubleshoot than one triggered by a distant side-effect.

What to Practice

Anticipate Failure. To fail early, we must get in the habit of creating hypotheses of failure. Then we can test those hypotheses by writing specs, asserting a method’s preconditions, or A/B testing a feature. Testing assumptions is easy compared to identifying them! How do we get better at noticing what our brains are taking for granted? In his book Design Paradigms, Henri Petroski asserts that judgment (by which he means the ability to anticipate failure) is an engineer’s most important faculty — and that the best way of improving our judgment is to study failures. By doing incident reviews, by reading postmortems and case studies, we sensitize ourselves to our own assumptions and get better at anticipating failures.

In case after case, the proper anticipation of failure has always been the mark of the most successful of engineers. Henri Petroski

Conclusion

Synergies

Certain pairs of these skills play well together and enable combo moves. A few examples include:

Slicing methods, objects, and services creates the need for more names; and clear names reveal seams.
Slicing tasks may reveal work that can be held until later.
Holding your Action will keep you from obviating every anticipated failure and steer you toward designing better signals of failure.

Optimizing the System

All of these skills are aimed at removing waste, but they don’t all remove work. Explaining Why, for example, adds work at every step. This would be inefficient if we were optimizing ourselves; but we’re not. We’re optimizing a system which includes the team of humans we work with, whoever will join later, and the robots on our team that run specs, perform deploys, and deliver information to us.

Fractals

These skills apply at different scales because the work itself is fractal. We apply the same principles when we slice tasks and teams as when we slice methods and objects. We can leverage that. In The Art of Learning, Joshua Waitzkin described his technique for elite performance:⁸ he translates mastery from the small to the large. He practices simple moves (a basic punch, a chessboard with just 3 or 4 pieces) until he deeply internalizes the forces and constraints at play. When the same forces and constraints apply in more complex scenarios, his intuition is primed to perceive them. Software development is staggeringly complex, but it is a fractal. A few skills (maybe even some of these) apply at every level.

It is rarely a mysterious technique that drives us to the top, but rather a profound mastery of what may well be a basic skill set. Josh Waitzkin

Endnotes

¹: The customer’s Why? comes from their deep knowledge of the Problem Space. What? is a point in the Solution Space. Your map of the Solution Space is likely better than your customer’s, but their map of the Problem Space is better than yours — they live there. Your ability to create value for them depends entirely on how well you can acquire their map. (See Clayton Christensen’s Jobs to Be Done framework and the first three chapters of About Face) back
²: I’ve included with my “Personal Rules” a few parenthesized statements: these are not lessons I learned directly by experience but principles I’ve read about that seem to fit with one of the five verbs. This principle, Indoctrinate in the Commander’s Intent, is how the modern military decentralizes decision-making while coordinating effort. (See chapter 9 of The Principles of Product Development Flow) back
³: “Vertically” refers to slicing a cake or a sandwich. If you cut a sandwich vertically, across its layers, you get smaller sandwiches. If you cut it horizontally, with its layers, you get bread, meat, or a slice of cheese — not a sandwich. Tasks should be sliced so each delivers a smaller piece of value. back
⁴: “The way to grow an organization is similar to the way to grow a code base. Whether it’s a monolith organization or monolith code base, you constantly figure out how to do cell divide, how to decompose or break apart so that you can get stronger boundaries and the ability to iterate in a way that you can make changes that don’t ripple through everything else so that you can reason about them independently.” (Interview with Alyssa Henry, April 2019) back
⁵: I borrowed the phrase “Holding your action” from Dungeons & Dragons. In a round of combat, a player gets one or more actions. Instead of using them immediately, they may choose to “hold their action” by saying so and describing the trigger that would release their action. For example, “I will hold my action until I can see the Gnoll and then I will fire a crossbow bolt.” back
⁶: “Jig” is a woodworking term for a custom tool that makes an action repeatable. A crosscut sled is a simple jig that holds a workpiece perpendicular to a table saw. By pouring your effort into creating a perfect crosscut sled once, you get the ability to replicate square corners endlessly. back
⁷: Advice given to Jim Collins by Peter Drucker (Interview with Jim Collins, February 2019) and expanded on in this blog post. back
⁸: Josh is an International Master chess-player and World Champion Tai Chi Chuan combatant. The book and film Searching for Bobby Fischer are based on his childhood. back

Testing 101: Structural Patterns

2017-05-19T00:00:00+00:00

ActiveRecord Patterns

2017-02-03T00:00:00+00:00

About Face

2015-05-09T00:00:00+00:00

Engineering departments follow rigorous methods that ensure the feasibility and quality of the technology. Similarly, marketing, sales, and other business units follow methods for ensuring the commercial viability of new products. What’s left out is a repeatable, predictable, and analytical process for ensuring desirability. p9, 4th ed.

Three degrees of separation

The obstacle to building a desirable product is seldom technical. It is the difference between you and your customer. There are counterexamples, of course — like James Dyson, Mary Kay, GitHub, and 37Signals — who have built products for themselves (and people like them) with great success. But most of us are separated from those we intend to help by three things: identity, space/time, and intermediaries. I mean:

We are not our customers
We do not work physically with them (and so do not get “live” feedback)
We do not communicate directly with them (but listen through a support team’s ears and reply through an interface)

Designing for oneself is exciting. You get the benefit of instant, visceral feedback as to whether your product is desirable or not. You get that same feedback when designing for others, of course, but then it can be misleading.

Alan Cooper’s About Face details a process for building the right product. And the first step is to tackle those three degrees of separation.

Understanding customers

If you want to create good design solutions, there is no avoiding the hard work of really understanding the people who will interact with your product. xxxiii

“Really understanding” customers goes deeper than identifying their chief complaints with the competition, recording all your conversations with them, or identifying the tasks they need to perform. These methods are quite enough to create lists of features to develop; but they can not discover whether those features are, in the end, desirable to your customers.

It’s impossible to know if something will be desirable just by listening to what the customer asks for — or even by looking at what the customer does. One must understand her context and her motivations as well.

Goals, not features, are the key to product success p25

Goals are the centerpiece of Cooper’s method. He outlines how to conduct research to ascertain them and how to design in light of them.

Research

The Research phase begins with ethnographic interviews. These are in-person interviews where the interviewer behaves like an apprentice to the customer: watching the customer’s behavior in-context and asking questions to elicit her thought-processes and motivations.

Back at the office, researchers identify the ways their subjects’ behavior varied, map subjects to those behavior variables, and look for patterns among them. Goals are deduced from patterns of behavior; and clusters of goals are fleshed out into personas. (Personas are not average or stereotypical users but exemplary users with specific goals.)

Understanding customers’ goals gives us the insight we need to make desirable products; but taking the extra step to collect them into personas nets us two more benefits:

Personas elicit empathy and become a shorthand for empathic knowledge (which boosts the accuracy and usefulness of our built-in, visceral barometer of desirability).
Personas are typically ranked (and this gives us the perspective to say “no” to any feature for a secondary persona that would detract from the success of the primary persona).

Design

Armed with an understanding of the customer’s goals, a product team is poised to do something it would otherwise have no hope of: help the customer be awesome.

Interaction Designers at Cooper pivot from Research to Design by storyboarding scenarios of ideal interactions between the customer and the still-imaginary product. These scenarios define the customer’s needs; and those needs form the product’s vision: a statement of the problem the product is solving.

It is absolutely critical to define and agree upon the what before we move on to the next questions: how the product looks, behaves, operates, and feels. p114

Without that clear vision, there’s no way of testing the fitness of a design (which results in development taking a more meandering/expensive path to success). With that kind of focus, however, every team member can see how every detail of their work contributes to the customer’s success.

Interaction Design

Alan Cooper calls this process Interaction Design. It differs from Visual Design (which concerns itself less with behavior and more with brand to achieve an emotional response) and Architectural Design (which concerns itself more with the organization of code), although they are closely related. Interaction Design determines in large part what the product does, how it makes its state and options apparent, and how it responds to users’ input.

Humans treat and respond to computers and other interactive products as if they were people. We should thus pay real attention to the “personality” projected by our digital products. p218

Understanding customers’ goals enables interaction designers to articulate features in customers’ terms rather than implementation terms and to put users’ needs ahead of the computer’s. A deep understanding of—and empathy for—them makes it easier to see what tasks are superfluous and can be eliminated, what error messages or notices are irrelevant, and what input constraints do more to serve the database than the customer. The result is a product with a more courteous, intelligent, and respectful “personality”: a more likable product.

How to read a project’s dependencies directly from git

2012-09-07T00:00:00+00:00

I have a program that lists all of my company’s projects and various statistics about them. Between little APIs, background services, and large applications, we’re getting quite a collection of Rails projects. I decided to add a column to show which version of Rails each was running—a column that would be automatically updated.

It turns out, it’s pretty easy to do with grit and bundler.

require "grit"
require "bundler"

repo = Grit::Repo.new(PROJECT_PATH)
lockfile = repo.tree/"Gemfile.lock"
locked_gems = Bundler::LockfileParser.new(lockfile.data)
rails = locked_gems.specs.find { |spec| spec.name == "rails" }
rails.version

The Design of Everyday Things

2012-05-05T00:00:00+00:00

Good Design

In the first chapter of The Design of Everyday Things, Donald Norman pokes fun at bad designs. He mocks smooth, beautiful doors that give no indication of how to open them and complex office phones with more functions than buttons. But users rarely see these as failures of design. People are more prone to blame themselves for being unable to figure out how poorly designed things work.

When a person uses a device, she builds a mental model of it: a conjecture, an imaginary explanation of how it works. To have success with—and to enjoy using—the device, that mental model must be consistent with the way the system really works. Design, says Norman, is “an act of communication” between designers and users. In this conversation, “all communication takes place through the system image.” The “system image” is the whole appearance and operation of a device including:

How it indicates what state it is in
How it indicates what actions are available (and which are not)
How it indicates the results of a potential action (before and after the action is taken)

A device that clearly communicates its state, available actions, and their consequences “disappears,” says Norman; and the user is able to “work directly on the problem at hand without having to be aware of the device.”

Tools for Design

How can a device so effectively communicate its image? Norman enumerates several tools: Visibility, Natural Mappings, Affordances, Constraints, Feedback.

Visibility: A device’s functions should be visible. Less frequently used functions may be hidden to reduce the apparent complexity of the device; but at all times, it should be apparent to the user what actions are available and how to perform them.
Natural Mappings: As much as possible, controls should bear a metaphorical relationship to the real world: they should have a “natural mapping”. (Norman draws several examples from the layouts of light switches and compares them to the positions of the lamps they control.) Any design that requires labels, diagrams, or instructions, he says, is probably faulty: unnaturally mapped.
Affordances: Affordances, like natural mappings, are clues (often visual) that suggest how a control may be manipulated. Handles on doors afford grasping and extruded buttons afford pushing. Affordances help users to discover how to evoke the actions a device has made visible.
Constraints: “Affordances suggest the range of possibilities, constraints limit the number of alternatives.” Constraints make it harder to commit errors. The mechanisms that make it difficult for you to lock your keys in your car are a kind of constraint. (In chapter four, Norman discusses four categories of constraints: physical, semantic, cultural, and logical.)
Feedback: There are two aspects of action: execution and evaluation. After executing an action, we watch for its effects, see that it accomplished what we expected, and adjust our expectations or intentions. Rich feedback about actions gives users confidence about a device and emboldens them to explore it.

The Process of Design

Much of The Design of Everyday Things is dedicated to the tools listed above; but its last two chapters reflect on the difficulties of the design process.

The gap between designer and user makes it just as difficult for the designer to understand the user as for the user to understand the device. Norman widens that gap with two observations:

First, there is a difference in how designers and users approach a device: “designers often become experts with the device itself,” whereas “users are experts at the task they are trying to perform with the device.”
A second difficulty is that “most designers…are separated from the end users by multiple layers of corporate bureaucracy, marketing, customer services, etc. These people believe they know what customers want and feedback from the real world is limited by the filters they impose.”

How can the gap be managed? To some extent it may be closed. “Much good design evolves.” Wherever possible, design and release in smaller increments. When design iterations and user feedback happen in smaller cycles, the conversation between designer and user approaches real-time.

For avoiding pitfalls in the gap between designers and users, Norman offers a few bits of advice:

Problems dominate users’ perspective; design for the problem case. Norman devotes an entire—excellent—chapter to thinking about errors.
Resist the temptation to design primarily for aesthetics. The primary goal of a device is rarely to “wow” an audience, to win an award, or to please a client. Keep its purpose in terms of its users in focus.
Fight creeping featurism. “Feature creep” has become a familiar byword, but Norman offers an insightful solution to it: modularize. This is similar to the single purpose rule in programming: each function should do just one thing and each class should represent a single concept. Higher up the software model, the best applications solve a single problem—and cooperate with applications that solve related problems.

The Principles of Product Development Flow

2012-05-05T00:00:00+00:00

In the past you may have been told that the key to economic success is efficiency…[or] conformance to plan… I would suggest that both of these popular beliefs are fundamentally wrong. The key to economic success is making good economic choices with the freshest possible information. p235, emphasis mine

Armed with the wrong definition of economic success, we would naturally measure—and optimize—the wrong things. At best this wastes effort, at worst it invites failure. Reinertsen’s goal in The Principles of Product Development Flow is to identify flaws in the conventional wisdom and to equip the reader with modern insights into product development. In support of his arguments, he draws on fields as diverse as lean manufacturing, economic theory, queueing theory, telecommunications, operating system design, and maneuver warfare.

The Principles of Product Development Flow is organized into 9 chapters and 175 brief principles.

Making Good Economic Choices

Perhaps the single most important weakness of the current orthodoxy is its failure to correctly quantify economics. p4

Product developers measure things like cycle time, value-add time, and other “proxy variables”. What we don’t measure is how these variables interact. As a result, we can’t answer questions like Which is less expensive: a 1-month delay or a $5,000 increase in expense? or Is this feature worth pursuing if it will take twice as long to implement?

To answer these questions we must express metrics in a common unit, lifecycle profits. Converting everything to dollars also reveals a critical insight: the best business plan is seldom the optimization of a single proxy variable. (It’s seldom the most efficient or quickest-to-market plan.) The best plan tends to be a “u-curve optimization” that optimizes the trade-offs between single variables.

The Freshest Possible Information

To manage product development effectively, we must recognize that valuable new information is constantly arriving throughout the development cycle. p38

Reinertsen likens product development to warfare. There are significant unknowns; new threats and opportunities appear continually; small advantages or disadvantages can yield disproportionate results. Payoff changes constantly: endeavors become more or less costly and more or less profitable, continually altering the optimal strategy.

When the best-laid plans have short shelf lives, learning becomes a vital competence. Faster feedback, earlier validation, and shorter cycles all fuel learning and enable product developers to make good economic choices with fresh information.

Queues

Optimizing trade-offs and maximizing learning are insights basic to Reinertsen’s view of product development, but they are not the focus of his book. Reinertsen spends more time developing the powerful concept of queues.

Today we realize that inventory is the biggest source of waste in manufacturing. Work product lying idle on the factory floor destroys quality, efficiency, and cycle time. p34

Queues are invisible inventory. Long queues of work-in-progress destroy quality, efficiency, and cycle time. They have many detrimental effects, but because intellectual work-in-progress is difficult to see, queues often go unmeasured.

Queue size is an invaluable metric, but like any proxy variable we do best to express it in economic terms. Estimating the cost of delay for a feature or product enables us to manage queues from economic facts.

Recommendations

The Principles of Product Development Flow contains 175 principles. Many of them cluster around a few important themes:

Make queues visible. A Kanban can be used to show work-in-progress in real time while Continuous Flow Diagrams give many insights into queues over time.
Reduce batch size. Iterating quickly minimizes the impact of queues without adding resources. It also accelerates feedback and learning. Focus on reducing transaction cost—the cost of releasing a batch—to make smaller batches more affordable. Unit Testing and Continuous Integration are strategies for lowering transaction cost in software development.
Plan in advance for flexibility. Flexibility enables you to react to emerging queues. Reinertsen’s most frequent example of planned flexibility is cross-training employees. Hiring reserves is another.
Prize initiative. Those closest to a problem can react quickest—and with the freshest possible information. Empower them to seize opportunities while coordinating a team’s efforts by establishing a shared vision and setting parameters for decisions.
Co-locate workers. The best way to shrink transaction cost in communication and to foster a shared vision within a team is to put teammates in the same room.