As a leader, how many times in your career have you come across a situation where teams are not aligned on a common goal? You know that you spoke to all or most of the members of the team about the purpose and approach for a project — but now it is going in a direction that is not focused on the business problem that you are trying to solve. You may have a case of what I refer to as the sitcom theory of communication at the office.

Taking a step back…

Three’s Company was a popular sitcom from the 80’s and used a very formulaic process for all of their episodes - every single one. The sitcom was about three people, one guy and two ladies that shared the same apartment. The owner of the building, Mr Roper, thought that they were swingers and would keep trying to find out what was going on. Most episodes consisted of the same plot — Mr. Roper would hear part of a conversation often hearing something out of context. He would make the completely wrong assumption and then the story would move off in very funny hijinks only to be cleared up in the end in hilarious form.

There is a version of this that happens at work — but the results are often much less humorous. I call this the Sitcom Theory of Communication at Work.

I work in software and the hardest thing about most software programs is people and communication (and people). A lot of the problems stem from the following mistakes:

  • Jumping to a solution very quickly and not understanding the full context of a situation
  • Someone listening (or not) in order to respond and not to understand
  • Not thinking through a whole problem in the mindset of what is best for the business — often just thinking about their own proposed solution/agenda
  • Multitasking, not respecting the viewpoint of the person that is talking, or just poor communication skills
  • Having a different opinion or objective and not really focusing on what is best for the business
  • Not fully respecting another person in the conversation
  • Missing the signal from the noise

There are numerous blog posts, talks, and books that all state that understanding the business problem and the complete context of the user experience BEFORE committing to a solution is KEY for major success — but we often forget about this when we are in the moment. In the book “Nudge: Improving Decisions about Health, Wealth, and Happiness”, authors Thaler and Sunslein define this as our Automatic Thinking process which is “rapid and is or feels instinctive, and it does not involve what we usually associate with the word thinking”. It feels good to begin work on a solution, doesn’t it?

With that said, it is hard to realize when you do this, I find it easier to identify when someone else goes down this path — especially when it is a team that works with you. This is one of the force multipliers you can provide a team. The purpose of this article is to point out how to how to identify when it does occur, how to correct them, and tricks to limit the chance of these situations occurring in the first place.

How to identify a sitcom situation

Listen and think. It is really that easy. As a leader you need to not be the one talking all the time and take your time to listen to other points of view and think about why they are going in the direction that they are. Where this gets difficult is how often to engage these teams. As a leader you should be hands off with most of your initiatives or you will just get in the way and slow them down. However you should still remain in touch with your teams. Some leaders prefer weekly status meetings, other prefer the managing by walking around method. I kind of like a little of both depending on the situation and the criticality of the project.

It is important to read people in these types of situations. These situations often lead to friction on the team which leads to stress which leads to unfocused work which is waste. Streamlining these situations is key to delivering the most business value you can [which is your job].

The best way IMHO is to have someone write out the logic and decision making that they used along the way to justify their paths forward. This can be simple, but in todays fast paced environments it is often overlooked, ignored, or dismissed with the addage of documentation becomes stale. I find that remote teams using tools like slack or Microsoft Teams CAN do this well if they have this same approach.

In the more traditional teams approach, one way that I have found at identifying these situations is from asking two different roles about challenges in the project and listening to what (and how) they say it and especially WHAT THEY DON’T SAY. Every team member should be able to articulate WHY this functionality is so important based on the domain. This is how I do it with my current teams. One of the main responsibilities of my job is being the delivery manager for multiple agile teams. Between technical challenges, requirements, product owner feedback, personalities, personal and team level agendas, and pressure around deadlines there are plenty of chances for these types of situations to arise.

This is my hands-off approach. I join the teams when they are discussing their designs. I sit in these meetings and try to not talk at all — I just listen to what they are saying and how they are collaborating. I usually only jump in when some kind of business clarification is needed or they want my input on a crucial decision. From these meetings I get a very good understanding about how the teams and the work is flowing. Each of the decisions and tradeoffs should be touched on in these meetings and they should tie back to the business value of the work. I get to understand how well they understand the business value by the way they discuss it in the meeting. The other side of the story I get is from the project and product management status meetings. In these meetings the project and product managers bring up their thoughts and concerns about the current projects and how the teams are responding. Listening to both perspectives allows me to see where there is friction or misalignment across the teams. At that point I will usually clarify the item on the spot or I will give one side some questions to go and discuss with the other side to get more understanding.

This is my most hands-on approach and only use this in urgent situations. I join the team for each and every meeting and clarify everything. I make people verbally describe everything at each step. We all sit in the same room together and use a white board to manually update items as we go through them.

I hardly ever use the extreme hands on approach — only if there are valid business reasons like a production outage or a critical (non-rollback) situation. This kind of management process kills team morale and should only be used when absolutly necessary.

My typical approach is to join the planning meeting per iteration, design (the most fun of all the activities), and any status meetings.

Tricks:

  • Never let a team get too far
  • Look for the questions that the team is not asking
  • Look for a leap in a discussion to the solution — make sure it is not too soon — no matter how much pressure is on the team. Doing the wrong thing is always slower in the l long run
  • Make sure the right people are involved (the whole team including stakeholders / SMEs is ideal) — watch out for decisions by cliques [never healthy]
  • Adjusting along the way is good and healthy but the team should clearly be able to identify what they have as an open decision and what the criteria is for making that future decision
  • Write shit down — seriously just do it. The reasons you are making decisions are the best things to document in any project. They should include the business justification, the tradeoffs, and the thought process that led to the decision

Oh no, this totally happened on one of my projects

  • Don’t let these misunderstandings go, no matter how painful the conversation is going to be
  • Fill in the gaps — you are responsible for conveying in a matter of fact tone the misunderstandings across the team and getting everyone in alignment
  • Pull together everyone — build teams and tear walls down

What can you do to be proactive?

  • Always bring up what the business problem we are trying to solve is
  • Always be clear and vocal with WHY we made certain decisions [Write them down]
  • Always have your door open to discuss any topic — not matter how taboo
  • Be diligent
  • Make decisions with a common framework aligned to the business strategy AND always make them for what would be best for the business

And always, having fun solving problems