What is the best way to motivate your peers to "go read up about it" vs. explaining them everything at that instant?

Question

We have many cases where colleagues with different experience levels are in a meeting and discussing potential software design(s). And another set of engineers who don't "get it" and would rather simplify everything - by simplification I mean "simplify to their understanding" and not necessarily adopt the suggested principles/practices in our domain.

At times, meetings have been derailed just so that we get provide a knowledge dump, which is exhausting with all cross-questioning/teaching etc., and then are they on board.

We've had discussion where we've explicitly given them some knowledge dump and provided links/books/references to follow up on the others. However, the "follow up" never happens and we're back to square one. It seems there's resistance in putting up the effort to "read up about it" and then come back with questions/clarifications/suggestions vs. argue about it right there and go back not feeling convinced and just leaving it at a stalemate.

What are good ways to "motivate peers" to "study/learn" new things vs. derailing meetings to explain everything to them?

UPDATE: This is not as straightforward to "Google it". It's more difficult than a keyword search but more of understanding underlying concepts and why things are done/preferred in a particular way. At times, books do a much better job than Google. The idea is probably to go a little deeper into the topic and make sense of the disparate sources of information to understand something that may take a few hours worth of mulling/understanding vs. a few minutes of Googling. It's about "lack of domain expertise" and unwillingness to "build it up" vs. "explain it to me right now".

Answer 1

It Sounds Like You’re Wasting People’s Time

I see two problems in your question:

1. You have meetings that are about a general topic (software design), but don’t seem to have a concrete goal or purpose, at least not from the description in the question and the comments on the question.
2. Some people attending the meeting do not seem to be willing or able to contribute anything to it.

I suspect Issue 1 partly causes Issue 2.

Meetings Should Have A Specific Goal or Purpose

At least in my job in the software industry, we do not have abstract discussions about the design of our software, because we’re busy doing work. We have design discussions when we’re designing something new, or when we’re making a change to something we already did, i.e. when we’re about to do some work that’s going to affect specifcally identifiable other members of the team.

If this is a meeting where people just “throw ideas out there” about what the design should look like, it doesn’t sound like there’s enough planning of the meeting’s agenda in advance for whatever the topic of the meeting is supposed to be. Whoever is running this meeting should know enough about what needs to be done or what specific problem the meeting will solve, that they can prepare the other attendees for the meeting in advance, (e.g. with documentation, notes, slides, whatever) so people can arrive at this meeting knowing why they are there and what they’re talking about. Which leads into your other problem:

Invites to the Meeting Should be Limited to People Who Can Contribute To It

You say in the question that these people who aren’t doing the learning that you would like them to do are peers. In other words, that you are not their boss. I assume that means they have a boss that has expectations of them that are different from yours, and that your peers take those expectations more seriously. Did you consider that maybe your peers don’t want to be at this meeting? I mean, if they wanted to be there, I think they would do all of this reading you want them to do without having to conjure up how to get them to do it. Or if their boss wanted them to be there, that they would do all of this work. Your boss doesn’t have to wonder how to motivate people, right?

It’s also possible that you may have overestimated their relative ability to understand or care about the topic of these meetings for some other reason. Maybe they’re not really your peers? Maybe you’re expecting them to perform at your level when they aren’t there?

Those are only two possibilities; there are countless more. Regardless of the reasons why, it’s clear that they are unable to contribute to the meeting productively. So, don’t invite them.

This goes back to planning the meeting with a specific goal or purpose. If the goal is to discuss the design of feature X, then you only need people who will implement X and people who understand the requirements for feature X. Maybe you have the testers for feature X also (if your organization has testers).

If you think the meeting attendance list is so limited already, then you need to improve the pre-meeting preparation so that everyone will have at least some idea of what everyone is talking about.

Answer 2

You need to show people why they are wrong, or accept that you might be

If the problem is that people genuinely lack the relevant domain knowledge, then you need to walk them through why their approach is problematic. For example, if the problem is parallel execution, you need to show why a naive approach could lead to race conditions.

In truth, nobody likes to be shown to be wrong, and following such an explanation, they are more likely to trust your ideas.

If it is really a matter of opinion

Of course, it is also possible that you have read book X, that enthused about a particular design, and your colleagues have not. That doesn’t make them wrong, and they may also have valuable experience, or another equally valid approach.

In software, there are many, many books and many, many opinions. If you think your approach has value then sell it, explain why it is especially applicable to the problem domain, but be prepared to respect and accept that the consensus may go in a different direction.

Dismissing your colleagues as ignorant or in need of education simply because they are not enthusiasts of your favourite book or author will not get you far. And don’t fall into the trap of thinking “everyone” solves a problem a particular way because your book says so.

Answer 3

The real solution is not in your hands, but in your boss's (or whoever is in charge of the project). All you need to do is make that clear to them.

First explain the problem to them in very simple terms:

1. You are tasked with coming up with solution designs.
2. These designs require buy in from other teams.
3. The other teams lack the expertise required to understand your designs and why they are preferable.
4. Your attempts to impart the knowledge that would help them understand are failing (through no fault of your own).
5. This is causing delays on the project, and extra work for you.
6. The lack of expertise on its own should raise concerns about the viability of that team/individuals being allowed on the project or in the company.
7. Lack of expertise is both understandable and remediable, but lack of pro-active learning, especially follow up on the recommendations you have advice, is really not.

Then, ask how they would like you to handle this. Here are some options:

1 - Be granted responsibility for training the other team

This will require both an allowance for time, and the authority to instruct them. However, there are some things you simply can't train someone to be if they are not passionate and proactive, which it seems they aren't so it won't work.

2 - Be granted the authority over the other team

Get the bosses to acknowledge that you know what you're doing and the other team doesn't, so do away with the need for their approval, or even understanding, and essentially put you in charge.

3 - Ask for the team to be replace by a more competent one

You may be able to outsource, recruit, place part of your team into theirs, or a combination of those.

4 - Carry on explaining things the way you do

Which will incur delays, and waste company time.

5 - Stop explaining things

Which will just create a stalemate.

Of course, none of these solutions are palatable, and putting them to your bosses will at least make them understand the predicament they are in. If they don't make a choice, your only solution is to implement option 5 and keep repeating the same thing at meetings:

This is the best solution. We are sorry you lack the expertise to understand why it is so. We are not in a position to give you the training required for you to reach the level of expertise to understand it. We have given you pointers and you have not taken them up. Our hands are tied.

This will create a very awkward silence in the meetings. Just smile and do nothing. The clock is still ticking, and he people who care most about that clock ticking will soon do something about it.