How to communicate effectivelly with less knowledgeable individuals

Question

Possibly related to How to communicate technical obstacles?.

In my current position I have found myself in difficulty when it comes to communicating technical difficulties or project management difficulties.

A bit of context: I work in a startup of 15 people, out of which 4 is our development team with me as the oldest one in the project (2 years), but the youngest in terms of age. There are often situations where I am asked to estimate the time of a given task where the difficulty level varies wildly. The code base was built by me over a 1 year period. Because I was the one always in charge of it, it is assumed that somehow I know every single aspect that can go wrong and that changing things is a linear process. Recently, our team grew and now I have the responsibility of managing the new team members as well as partially overseeing our project. For this we decided to use scrum. I have no issue with scrum, I have worked with it before and know my way around it. The COO and CEO however have never worked with it before and they are learning it now. Because of this, we did a half-way implementation of scrum where they decided what features to use or not. The problem is, they decided to remove user stories completely which is a massive mistake in my opinion as it removes a whole layer of validation of our progress.

The problem that I am facing is very often, I am unable to communicate clearly what the problem is. Although I can give clear answers and solutions when prompted too, a lot of the times I am faced with open questions from them such as "Why are user stories important? It's just a phrasing of a functionality." Or "Why does it take so long to change one text field?"

What are some ways to improve my communication to reach out the people that are not so knowledgeable in a topic? A lot of the times I feel that I am met with skepticism because I am relatively young (26 years), which seems to be more important than the fact that I have been working in software development for 5 years.

Answer 1

Self-checkup

First of all, I would suggest you do a self-checkup. You seem to be handling a lot of things all of a sudden. If you juggle with to much stuff, you will inevitably drop some on the floor. So first thing you need to do is to sit down with yourself and see how much you can realistically do, which are the things you need to handle, and which are the things you cand delegate or let someone else handle. Be also aware that you will probably need to train the new developers for them to learn the code base, be available for questions, etc., so even more work comming your way. You mention you have a "general scrum master" so ask them for help. You don't need to be the only one dealing with the Scrum situation.

Patience

You will need patience. People don't know what you know so you need to explain. There isn't a magical formula for how to explain, so you will have to develop this skill in time, with practice and patience. People will have a lot of questions, some will be annoying, some will be silly, some will be completely dumb, but you need to stay calm and have patience. If you think about it, it's kind of good that people ask questions, because that's how they learn. I've been in situations where ignorant people in high positions just uttered complete nonsense as instructions to follow, without asking for clarifying questions. So questions are good.

It's a learning opportunity

You will not have all the answers but you are expected to have all the answers. You built the code base, you manage the team now, you handle the Scrum process, so you need to have all the answers, right? That's what people expect from you. You will have to take note of things you get asked about and you don't know the answer to, and learn or find out the answer. "Why are user stories important?" Well, you should know. "Why does it take so long to change one text field?" This you should definitely know. For some of the questions you can say "I don't know, but I'll find out", from other questions you might not be able to back yourself out so easily. Accept from now that you will make mistakes and have some awkward conversations. Use it as an opportunity to discover knowledge gaps that you can then fill. For example, Scrum doesn't prescribe the use of User Stories, you have product backlog items. As long as everyone understands what needs to be built you can use anything. User Stories don't guarantee understanding.

Pick your fights carefully

When people don't understand something, they will be unaware of the consequences of their decisions. There will be things to disagree and fight for, and others you can let slide. Doing a half-way implementation of Scrum where they decided what features to use or not was a bad idea and you should have fought for keeping what's prescribed in Scrum. I'm not a big fan of follow the process and fake it till you make it, but having some structure in place to limit your choices is better than throwing away stuff or cherry picking on things they don't understand. Compared to this, fighting over User Stories becomes less important. Another important fight would be to make the CEO act as a product owner and actually manage a product backlog, properly. Otherwise work will be thrown at you whenever they see fit. That might affect your sprint, your planning, etc. They were used to work a certain way and they will not change their ways all of a sudden just because of this Scrum thingy. It will take time. At some point you might even discover you can't do Scrum properly if you don't have their collaboration. Think then if you want to fight for keeping Scrum or do something else (Kanban on top of what you were already used to might have been a better approach, for example).

So in conclusion, there isn't a prescribed way to explain things to less knowledgeable individuals. It's a matter of practice and building experience. Stay calm, have a lot of patience, and try to build soft skills. It gets easier with time.

Answer 2

The correct answer to your question is "I don't know", but that's not very helpful. In the effort to be helpful, I'll provide an incomplete and potentially nonresponsive answer.

Within the context of project management (I think a great deal of the reason why I don't know the answer is that your questions seems to scope far beyond project management), successful communications rests on communicating within two principles.

The first is your communications plan - I'm going to skip a bunch of the basics here, but before you communicate with the stakeholder, have a conversation with the stakeholder about what kind of communications they want. What do they want to know, and how should it be communicated. This includes both "Do you prefer email or phone calls, or office visits?", and "What's the threshold for reporting? Do you want to be told if the deliverable is 1 day late? or a week?" and a general understanding of how that stakeholder views their role in the project. "How will the success of this project affect you?"

The second is the iron triangle. PM communication is generally most effective when you can offer two things (1) an estimated impact on the project, and (2) one or more proposed courses of action.

I don't do scrum, (ironically, because like you, my management wants the illusion of scrum without any of the work of scrum), but I imagine the script is going to have to be.

• User stories are the way that we express requirements; they help us to manage scope and quality by expressing what "done" means in a way that everyone understands clearly. If you reject user stories, then we're going to have to spend time managing requirements differently. Based on my expertise and my research, user stories will lead to higher quality, less time in User Acceptance Testing, and less rework because people better understand the objective, and the deliverables will better match the intended use and quality. I propose that we give it one sprint doing it my way, and if we don't hit the target we can revisit the conversation. I have to warn you that there is also evidence that scrumbut is attractive but ineffective, and if you insist on pursuing that, we're going to have to spend a great deal more time on management and less time on delivery.

There is a third principle here that you're going to have to feel your way through. Are you the project manager or not? Do you have any authority? Do you choose the project management methodology? Or are the managers going to micromanage past you. In a good world they just need to be convinced that you are in control of the project, and the best way to do that is to provide them accurate, reliable, timely estimates and credible information. In a bad world, they think they know more than you do, and implicitly fail to respect you; that disrespect will quickly be evident to the project team who will learn to ignore you because the only opinion that matters is the micromanager. That's a dangerous place to be.

Good luck; that is a complicated, even wicked problem; I don't think there are any simple solutions.

Answer 3

Practice. It really doesn't matter what the topic is or if you're smarter than someone else or not. It's about practicing, explaining complex issues using simple, straight-forward language, using simple and everyday analogies, exhibiting patience, asking if they understand, and pivoting to another explanation strategy if you sense you're not getting traction. Practice explaining any complex topic to someone 10 years younger than you. Rehearse an explanation to yourself over and over again. Explain something complex to a few of your friends and then ask for feedback about what was good and what needs to get improved, then do it again.