15
Communications Breakdown
Entry Feed Trackback
Have you ever wondered why some projects or groups struggle so much to get things done? Have you ever been sitting in a meeting wondering why you’re talking about trivial things when there are much larger problems at hand. If your like almost everyone in today’s high paced world, more than likely you can relate. generally this is nothing more than a communications breakdown. Everyone communicates differently and no matter how you might think you’re communicating to them, the reality is you may be missing the target 100%.
Recently I was involved in a similar situation where small things were being escalated in a project and trivial issues were being presented as major risks to the project. This directly involved me as a roadblock. The reality was (in the end) it was nothing more than a communication style. I have a particular way I work within my teams and my organization and the way I do that lends itself to talking about problems before ever presenting the solutions. This is good unless your working with someone who looks at a problem and instead of presenting the problem to be solved they just throw out their solution. Tech people tend to want to walk thru the process of understanding the problem before a solution is thrust upon them and I’m really no different. I usually say “Don’t give me your solution, present your problem and lets work on a solution”. It’s really splitting hair because another way to look at this might be “Don’t talk about problems, lets present solutions” neither is wrong they are just differences in communications style.
I like an approach where I’m presented a problem, maybe for my organization, my personal character, etc and then I commit to resolving the problem and getting a solution in place. Others I’ve worked with over the years like to look at a problem, put a solution in place and present that solution as a step forward. Both have their values, one tends to gather more information first and get more buy in and the other focuses on moving forward faster and may not be as open for debate.
I’m a big fan of buy-in as I think without it you may drag baggage with you to your destination. The culture in my team is much the same, and most likely because that is the way I operate as the leader of my teams. Don’t get me wrong, I’m not perfect and I don’t always seek buy-in on every item I have to deal with. To me (IMO) the ”here’s your solution” approach can tend to make people feel like it’s a Top Down model and they can become resistent.
How do you communicate? Do you like to hear the problem first and then commit to putting a solution in place that take multiple things into perspective or do you tend to just look at the end point and present your solutions to getting there? How does it work for you?
It really boils down to the fact that you have to be flexible and know your audience and the people who work with you on a daily basis or it will cause you heartache and really put stress on your organization.
Interesting post. I think I sit somewhere in the middle. I want to hear about the problem, but I don’t want to hear about all the problems. I want to find out enough to know what the largest part of the problem is, and what the root cause is, but I don’t want to hear all the little details and problems branching off of the root cause.
Equating this to compiling code. (More so in the old day when syntax wasn’t checked as you typed.) When I used to compile code after writing code for a while. I’d go and fix the first problem in the compiler and re-compile. Often by fixing one problem the 50 compile errors drops down to 30. The other errors cascaded off the original.
Going back to the topic of communication. My preferred method is to hear enough about the problem to determine what I think is the root problem. Try to solve that problem, and then adapt. Add more solution if needed, hear more problem if needed. I like to make the feedback as short as possible, and only try and solve one thing at a time.
John Sonmez at Apr 27, 10 at 11:04 am
This is an interesting challenge that is a part of building software everywhere. Given that software development is an empirical process there is almost never a silver bullet. As a leader I have found that a hybrid approach to problem/solution tends to work best. The hybrid approach includes a clear articulation/understanding of the problem followed by a reasonable/defensible set of solutions with a recommendation. I expect people to have thought through the problem and possible solutions so that a meaningful conversation can follow. I also expect people to have an opinion on which solution is best. It is dangerous to rely on leadership to provide solutions. It creates a culture of dependency, which will ultimatly lead to a lower throughput on teams as they lose the ability/motivation to problem solve on their own.
I also agree that buy-in is important and I typically encourage people to “socialize” important decisions/changes to help formulate the recommendations while bringing people along with them as a part of the solution rather then feeling like it is being fed to them.
In the end you want to build a culture of passionate people who feel empowered to solve the challenges that they encounter. The more you can foster this style of building software the better your results will be from team morale to raw throughput.
David Montz at May 20, 10 at 10:11 am