Vrftsjtryk

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".

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.