Sitcom Theory of Communication at the office
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 very funny sitcom from the 80’s used a very formulaic process for all of their episodes. The sitcom was about three people one guy and two gals that shared the same apartment and the manager 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 [jumping to conclusions]
- Someone listening to someone else talk in order to respond and not to understand
- Being stubborn and not thinking through a whole problem in the mindset of what is best for the business — often just thinking about their own proposed solution
- Multitasking, not respecting the viewpoint of the person that is talking, or just bad 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 and 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 enough to realize when you do this, it is even harder to identify when someone else goes down this path — especially when it is a team that works with you. 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 thinking the way that they are. Where this gets complex 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 stats 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 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 timelines 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. 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.
My typical approach is to join the planning meeting per iteration, design (the most fun of all the activities), and any status meetings. I recommend that you have 2–3 teams and any more than 4 is too much.
- 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 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
Originally published at software leadership blog.