If you spend much time around the offices at Atomic, you’ll eventually hear someone mention the phrase “zooming out” in relation to solving a problem. I’m not 100% certain on the origin of our use of the phrase (we may have picked it up from one of our friends at IDEO or Cooper), but I’ve used it frequently over the past two years. And the more I use it, the broader my definition becomes. It’s just so darn useful.
So, what is “zooming out”? Why is it important, and how have we applied it to our work?
To attempt a concise definition that captures the broad strength I see in the concept, let’s start here:
Zooming out means opening your mind to a broader context surrounding the details of your current focus in order to consider alternate solutions to a problem.
Zooming Out in Action
An example should help illustrate the simplicity better than my definition.
- The situation: I’m stopping by the store on my way home from work to pick up ground beef for tonight’s dinner — it’s Taco Tuesday! After making a right turn just a few streets away from my destination, construction and a traffic jam halt my progress. This could take a while. Drat.
- Not zooming out: I stay focused on my position in the clog, just trying to squeeze my way through the construction blockage as quickly and efficiently as possible. My goal is to get past the construction.
- Zooming out: Wait, my goal is to get to the store. An alternate route around the construction would probably get me there more quickly and with less frustration.
- Zooming out: Other stores probably carry ground beef. Think… think… yes! The small grocery just a mile out of the way in the other direction would probably be easier to get to.
- Zooming out: Is there anything else I could use to make tacos? Maybe we could shred the chicken leftovers and I could skip this whole stop by the store.
- Zooming out: Tacos shmacos. All my wife and I really wanted tonight was a relatively quick meal before heading out to work on hanging Christmas lights on the house. Let’s make the mac ‘n cheese we had planned for tomorrow night. We can do Taco Wednesday instead.
So, that’s it. That’s zooming out. We do that sort of evaluation and decision making every day. The concept is really that simple — it’s being prepared and knowing when and how to apply it that’s more difficult.
In the Taco Tuesday example, I was well-prepared to practice zooming out. Imagine if I had been missing a few pieces of information, though. Working from the bottom up, how would the outcome have been different if …
* I didn’t know we wanted a quick dinner in order to move on to a higher priority for the evening?
* I didn’t know about the available chicken leftovers?
* I didn’t know of another store where I could pick up ground beef?
* I didn’t know the roads well enough to plot an alternate route?
The number of options at my disposal shrinks quickly with a few missing pieces of information. The worst case scenario is that I make a decision that aligns with the goals I _do_ know, but hurts the ones I’m not clear on (e.g., Since I had to stop at the store, I bought ingredients to make our own tortillas! _Let’s spend the whole evening cooking!_).
Zooming Out on a Project
Software projects are a few orders of magnitude more complex than dinner — 2 hours of work vs. 2,000, or more. There are opportunities on a daily basis to zoom out and align our work with the goals we understand on a number of levels. It’s worth the time invested in being prepared.
How do we ensure the team is prepared to zoom out?
### We’re involved in research, design, and planning.
We like to involve the whole team in early project activities, like playing innovation games with our customers. This is a key time where we build an understanding of our customer’s business and key goals for the software we’re about to build.
### We collaborate on design and software structure decisions.
Pair programming, working together on design, and generally collaborating on how we structure a software system help equip more of the team to make good decisions when working on smaller pieces. Each person is more engaged in the ontology of the system.
### We stay involved in management.
Whether it’s project management, iteration meetings, or design reviews, I try to keep multiple heads in the game. When we immerse a project team in the broader discussions of project management, product design and management, market fit, and client goals, we equip everyone with better tools to evaluate how to best provide value on a daily basis.
## Three Triggers—the “When” and the “How”
A prepared team should be able to zoom in and out to generate possible solutions and evaluate their fit with real goals. But when does that happen, and how?
It’s easy to get caught up in the flow of solving detailed technical problems or develop a mental block that prevents zooming out at the right time. Having specific triggers helps me break out of those deep dives, but it takes practice and repetition to tune your intuition about when to zoom out.
### 1. Listen to observations.
When I find myself (or hear someone else on the team) making any of these observations, it’s probably time to zoom out. I’ve paired a good “zoom out” prompt question with each.
* This feature doesn’t quite fit the product.
* What value does it provide to a user or the company?
* This new method or concept isn’t fitting into the model (ontology) very well.
* How could we change the ontology to make the details fit better?
* The complexity of this feature is threatening to blow out the estimate.
* Is there a simpler way to provide a similar value? Maybe even without software?
* This is hard to test.
* Would it be better to test at a different level? Integration test vs. unit test.
### 2. Set points in time.
There are other natural points in the rhythm of a project where it’s a good idea to take a moment to zoom out. A few of the times I’ve been making a habit of zooming out are listed below, again with prompt questions that I like to ask myself.
* Feature Completion
* Does it provide the value originally envisioned for the feature?
* Iteration Planning
* Are we still focused on delivering the right features?
* Starting Development on a Story
* Who will be using this feature, and in what context?
* What other areas of the application are affected by this story?
### 3. Keep RDP artifacts close.
I like to keep RDP artifacts hung in the project area as a prompt for the team to zoom out. They’re great at pulling us out through many layers of context because of the discussions and conclusions they help us recall:
* Users / personas – Who is using this?
* The business ecosystem – What value does it provide?
* Low-fidelity wireframes – What are the really key features?
* Our client’s hopes and fears
* What ultimately means success for the project?
I hope that helps clarify the concept of “zooming out” and some of the ways we’ve been using it at Atomic. It’s a practice we’ve found useful in many contexts that isn’t difficult to get started with. Find a few of your own zoom-out triggers and get started practicing!