Architecture & DesignLesson Learned: Keeping the Focus on the Object of Focus

Lesson Learned: Keeping the Focus on the Object of Focus content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

I don’t know about you, but for me, getting a group of software engineers to make a technical decision is about as easy getting a family to decide on which band to hire for daughter Susie’s wedding. Everybody wants music, but brother Tom is a thrasher, mom likes to tango, Susie likes to wile away the hours on electronica and dad is all about easy listening, no dancing at all. So, the family gets together to brainstorm. The family starts yacking away and soon an impasse is reached. No decision seems likely. Finally, Dad puts his foot down and says “I am paying for this thing, so we’ll get a band I like.” The decision’s been made; only Dad is happy. Everybody else is pissed off.

Sound familiar? I’ve been faced with that problem over again: We come to place where a group of engineers agree that we all need to do something in a common way, but everybody has his or her own idea of what ‘common’ is. We go into a room to come to a consensus only to emerge hours later with nothing except frustration, bitterness, and anger.

I have come to learn that a battle of ideas is a waste of time, that there is a better way by which agreements can be made, money can be saved and success can be experienced. It boils down to following a single rule. Here it is:

Keep the focus on the object of focus.

Allow me to elaborate.

What Is an Object of Focus?

An object of focus is something concrete that can be responded to by everyone invested in making a decision. An object of focus can be a formal presentation, some code that is being reviewed, or a a list of benefits and risks. For a thing or activity to be an object of focus, it has to be demonstrable, immediate, relevant to the purpose at hand, and offer a lot of opportunity for rational response.

Engineers do well when they are talking about something that has immediate meaning. In my observation, when engineers start talking about the abstract or theoretical, it leads to religious wars: discourse based on a person’s beliefs rather than rational, objective thinking about a particular item. It’s hard to make a decision in a religious war. There’s too much at stake. However, narrowing a discussion down to single experience makes coming to a decision a lot easier. For example, instead of having to decide whether to go with Mediterranean or Italian cuisine for lunch, it’s easier to decide whether to have falafel or pasta. Or, going back to the wedding music situation, making a decision about which band to hire for Susie’s wedding will be a lot easier if everybody has a piece of music on hand to share with others, rather than just talking about the music he or she wants. The trick is have something on hand that can be experienced and talked about in real time.

Decide by Doing

Whenever I am to lead a meeting of a group of engineers gathered together to make a technical decision, my style is to make the decision by responding to an object of focus. I call such a meeting a Do-Storm. In a Do-Storm, if somebody has something to say, it needs to be relevant to the object of focus. The object of focus serves as the anchor for rational discussion. Good decisions are the result of focused, rational thinking.

Do-Storming is an easy concept to grasp, but a hard one to execute. To Do-Storm successfully, the meeting organizer has to do three things:

  1. Prepare well.
  2. Keep the focus on the object of focus.
  3. Have a structured approach to resolution.

A Case in Point

A while back, a group of developers was trying to solve a common problem: deploying Windows services that required special configuration settings based on the runtime environment. For example, if the service was running in a TEST environment, the service needed to be configured to access a database that was dedicated to TEST, a file system dedicated to TEST, a message broker that was dedicated to TEST, and so forth…. If the service was deployed to a PRODUCTION environment, the service had to access the PRODUCTION database, the PRODUCTION file system, the PRODUCTION message broker, and so on…. (Please see Figure 1.)

Figure 1: The solution scenario requires that a service be configurable according to the runtime environment.

Two engineering groups that were writing the two different services had two different approaches to supporting deployment configuration. However, both groups agreed that the deployment pattern was identical and that a common deployment method will save time and money for both the engineers and the enterprise. The groups agreed to meet to make a decision about a common way to deploy the Windows services. So far so, so good.

I agreed to lead the decision making meeting. After doing some preliminary investigation, I discovered that the services that were being written by each group were complex and that it would take a lot of time for engineers to explain their particular service. Also, I learned that the deployment solutions that were being developed were dramatically different. Thus, my gut was telling me that a free-form brainstorm among the two parties was going to quickly become a “Less Filling, Tastes Great” argument reminiscent of a past beer commercial. (Click here to view the commercial.) Something different needed to be done. So, I got to work.

Doing the Prep Work

To create an environment in which a decision could be made, I had to do two things:

  1. Eliminate as much complexity as possible from the common experience.
  2. Create an object of focus by which a decision could be facilitated.

Eliminating Complexity

To understand a complex idea, you have to give a lot of attention to understanding a lot of details. Such intense attention requires mental energy. There is only so much mental energy to go around. Thus, we need to be mindful of how energy is used. Spending time learning details not relevant to the case at hand uses up energy that can be used for the purpose at hand, making a decision. In this case, there was no immediate reason for each team to understand the complexities of each other’s work. All parties agreed that the deployment pattern being used by each group was identical. Thus, eliminating the complexities distinct to each group from the common discussion freed up energy to devote to coming up with a decision about the need at hand, deciding how to deploy a set of Windows Services. Specifically, I needed to create a simple use case that each group could process in terms of their deployment idea. That use case is the object of focus.

Creating an Object of Focus

As mentioned earlier, I needed to create a use case to serve as the object of focus. The use case needed to touch all the key technical points required by each engineering group’s activity and also be so simple as to not distract from the need at hand: to decide on a common deployment process.

So, here is what I did:

I wrote a simple Windows Service that wrote a line of text to a file at a given interval of time. Then, I attached the service to an email that I sent to the engineering groups. The email is shown in Listing 1. I asked each team to apply its deployment idea to the Windows Service use case I developed. This dopey little Windows Service provided the means to address the larger issue at hand.

To: Engineers

From: Bob

Subject: What to do about Windows Services deployment


Attached is a simple Windows Service that logs a line of text to a log file. The location of the log file directory and frequency for logging is defined in the service’s configuration file.


I created the Windows Service so that we can have a baseline experience by which we can come to a common consensus about to how to implement a standard method by which to deploy a Windows Service.


We have many ideas about a standard for deploying a Windows Service. To make sure we are doing an accurate comparison, please apply your deployment idea to the attached Windows Service and be prepared to demonstrate your thinking, supporting the following two conditions:


  1. Your idea must be supportable under continuous integration under the system Joel is developing.
  2. We want it so that different settings are applied to the service, depending on the deployment environment.


The version of the app.config that is attached applies to the local developer machine and has the following settings:


<?xml version="1.0" encoding="utf-8" ?>
      <supportedRuntime version="v4.0"
         sku=".NETFramework,Version=v4.5" />
      <!-- The location of the directory into which the log file
           will be written -->
      <add key="logFileDirectory" value="C:logs-local"/>
      <!-- The frequency, in milliseconds, at which an
           entry will be made into the log file -->

      <add key="logFrequency" value="500"/>


Your deployment methodology needs to alter the configuration settings based on the environment to which the service has been deployed, like so:



<?xml version="1.0" encoding="utf-8" ?>
      <supportedRuntime version="v4.0"
         sku=".NETFramework,Version=v4.5" />
      <!-- The location of the directory into which
           the log file will be written -->
      <add key="logFileDirectory" value="C:logs-test"/>>
      <!-- The frequency, in  milliseconds, at which
           an entry will be made into the log file -->
      <add key="logFrequency" value="700"/>


<?xml version="1.0" encoding="utf-8" ?>
      <supportedRuntime version="v4.0"
         sku=".NETFramework,Version=v4.5" />
      <!-- The location of the directory into which the
           log file will be written -->
      <add key="logFileDirectory"
      <!-- The frequency, in milliseconds, at which an entry
           will be made into the log file -->
      <add key="logFrequency" value="800"/>


I know that am asking you to do some unanticipated work in preparation for tomorrow’s meeting. I think there is significant value having concrete examples in play. Demonstrating a working deployment idea will allow us to get a lot of good information that will allow us to make informed, well reasoned decisions.


Listing 1: Having engineers address a simple common use case allows more energy to be spent focusing on the issue at hand.

I sent the email. Each engineering group agreed to demonstrate their idea. I scheduled a 1 hour session.

Running the Session

The engineering groups gathered together to demonstrate their deployment idea. At the start of the meeting, I cordially announced to the attendees that there was a risk that the meeting could become a “Less Filling, Tastes Great” argument. I asked the group’s permission to interrupt should I see “Less Filling, Tastes Great” rear its head. The group consented.

Starting with Little Decisions

One of the tricks I use when trying to get a group to make a big decision is to have the group make a lot of little decisions first. The decisions should be simple. For example, if you have a choice of meeting rooms, ask the group which room they prefer. Having a lunch meeting? Offer the group choices about where to send for take out.

At the beginning of the engineering meeting described above, I asked the group to decide if I could interrupt when I noticed they were going into, “Less Filling, Tastes Great.” The group agreed immediately. The decision was a small one, but it sets a tone in which collective decision making behavior is in force.

The presentations were structured, yet not overly formal. Each group showed how its idea met the criteria stated in the email. There was some question and answer after each presentation. Then, it was time the groups to make a decision: Plan A or Plan B.

Facilitating the Decision Making

There are a number of techniques available that allow groups to make a decision without having to do a lot of talking. Some organizations use survey tools such as SurveyMonkey. You create a survey that poses the decision to be made with options available. The groups respond. The Agile folks have First of Five. Me? I use an adaptation of a technique defined in TheCore protocols published by Jim and Michele McCarthy. It’s called Decider. I put the decision out there and the group does a binary vote, 1 finger for Plan A, 5 fingers Plan B. The point is to get people to declare at the same time. So, I say, “Fingers up on 3. 1, 2, 3!” And we vote.

The result of the vote about the Deployment Process is that all engineers but one wanted to go with Plan B. I asked the dissenting engineer what needs to happen to get you to go from Plan A to Plan B. His response was, “Oh, I just voted for Plan A because I thought it up and I wanted to have my way. But, as I review the information presented, Plan B is a lot better. So, I am going to change my vote.”

I wish all engineers showed the degree of honesty and self awareness of the dissenting engineer. We took another vote and Plan B carried the day. The important thing to note here is that the object of focus was the means by which information was presented, opinions were expressed, and a decision was made.

Putting It All Together

As strange as it may sound, when it comes to having engineers make a decision as a group, my preference is to stay away from brainstorming and keep talking to a minimum. As I mentioned above, engineers can easily engage in religious wars in which nothing gets done. However, engineers like to make things. That’s how they’re built. So, instead of brainstorming, we Do-Storm. In a Do-Storm, all activity and discourse happens within the context of an object of focus. Keeping the focus on the object of focus and using a decision making process the requires the consent of all not only saves time and money, but garners the investment necessary for a successful implementation of the decision once made. When you keep the focus on the object of focus, there is a good chance that all will go well; otherwise, as the commercial goes, all that’s left is “Less Filling, Tastes Great!”

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories