Coffee Shop DevOps: Clearly defining and communicating team goals

Last month I interviewed the Cockpit team about team practices. We had an interesting conversation from many different angles, but most notable were the themes we kept returning to: understanding goals, the importance of feedback loops, and committing to open and transparent communication. I found I could easily correlate each of these back to other teams I have worked with in the past. When you inspect the behaviors and inner workings of a team, these themes seem to be remarkably central to team conflict.

Understanding goals was one of the first items that resonated with me in terms of the Cockpit team. This month, I am going to focus on understanding goals that your organization tries to communicate, and how you can incrementally chip away at communication failures.

1. The goals are being communicated, but are not communicated in a way that is easily understood or noticed by everyone.

Let's inspect an exchange I had with a coworker during a group conversation. We were discussing high-level requirements to build reporting that teams need internally. Before the conversation closed, the engineer asked me, "Can we use an open source solution?" I thought he was talking about looking for pre-existing open source solutions, so I said, "Yes, absolutely use an open source tool." I started pointing him toward a few that I had seen, when the third person in the conversation explained, "No, he means can his code be stored on GitHub?"

Words matter. Like it or not, misunderstanding one another is incredibly easy, even when we are having a face-to-face conversation as we were that morning. The misunderstanding that occurred was over a simple sentence. What happens when the message being communicated is more complex? Do you think that miscommunication increases? I do.

2. The goals are not being communicated and employees are just meant to do as they are told.

I could spend time talking about the negativity that the sentence above represents for any organization; however, if we break it down into parts, which part hurts the most to read?

• Goals are not being communicated.
• Employees are meant to do as they are told.

The temper-tantrum two-year-old in me wants to say the second one, but I think there is more harm hidden in the first sentence. Let me explain: If the average employee has no insight into what the overall goals are, nor even an inkling about what kind of decisions should be made in the moment they need to be made, they will soon find themselves in a holding pattern waiting for someone to tell them what to do next. A team member not empowered to make a guided selection of what steps should come next will effectively contribute to a decrease in initiative—the official "passing of the buck," otherwise known as lack of accountability, and an overall reduction of morale to go with it.

I look at this as the "push" model of working—someone assigning bugs or tickets to you. You wait for the next task rather than understanding the overall goal, how to work toward that goal, and which course corrections—minor or major—that will lead the team there. Sometimes this model of working can be fine for an organization, but my experience tells me that it is not for larger organizations.

Often we think that this is the model that will yield the greatest results, especially when there is a failure to trust the folks who work for us and with us. Assigning the work somehow implies that it will be completed because it was assigned. When it is not completed, you know someone isn't doing their job. It's quantifiable. Does this sound familiar for your organization?

How do we break these chains and escape these problems?

Although some of the problems happen at an organizational level that can't be addressed by an individual, we, as individuals, do bear the burden for the correction.

• Individually understand the goals: Have you caught yourself in a situation in which you didn't understand a goal being set for your team? My straightforward advice is to continue asking questions until you understand the goal. Do not settle for a vague explanation. Now, you may not get every last one of the details you need, but you do need to understand the problem set or the goal you are trying to achieve at a high-level. It's fine if there is follow-up research or conversations to uncover the rest later.
• Pay attention: If someone is talking about problems needing to be solved, pay attention to the person. In fact, give them your full attention. It might be a challenge in a day where multitasking is the norm, but I do hope that I don't need to explain the dangers of that. Are you possibly thinking that when you listen to certain individuals in your organization talk about goals it is... perhaps a bit boring? Could it be because you don't understand a word they are saying when they talk about needing to synergize the value-added impact of the next fiscal quarter to add a revenue stream in the cloud? Yeah, me too. Here is a clue: Tell them you didn't understand. Challenge them to explain their goal without buzzwords. Paying attention also assumes one critical thing—you care about what you are doing for a living and the people with whom you are interacting. If you are past that state, it is going to be a hard road.
• Help your team with communication: Be ready and willing to explain what you understand and the why you are working on something to others. Just because you understand it doesn't mean someone else does. Just because you think you understand it doesn't mean you do—always be curious about someone else's perspective. This includes both people who are on and not on your team.

Additionally, don't assume that communication is easy and that just sending out an email means you're done. A few years ago, I had an announcement that needed to go to a broad audience of people. I was concerned about how likely it was that the information would be read, much less retained. In this particular case, that the announcement was read was important. In absence of a game plan, I asked for advice from an internal communication specialist. Her advice stuck with me to this day: Expose people to at least three different methods of communication. This will help them retain and possibly understand what you are trying to communicate. Methods include things such as email, video, face-to-face, other technology (centralized dashboard monitors, an app, wiki page for your company or project), and verbal. Don't make the mistake of sticking to one method.

Communicate your important messages on days in which they will be more likely to be consumed in a timely fashion. Friday and Monday are notoriously bad days. Tuesday and Thursday are typically ideal.

Stop assuming that every problem needs to be treated like another fire that needs to be resolved before it becomes an escalation. And stop attempting to solve the problem before you even understand the problem.

When you slow down, communicate clearly, and take the time to grasp the problem fully and make sure everyone is on the same page, all of these problems with understanding goals can be avoided.