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

  • 3
    Possible duplicate of How to politely ask a coworker to “Google it”
    – DarkCygnus
    Commented Apr 26, 2019 at 22:32
  • @DarkCygnus - it's not entirely "Google-able" IMHO - this is deeper than just "keyword search" but more like "knowledge gained" - probably multiple google searches linking disparate ideas. Unfortunately it's hard to "google it" exactly so we tend to save books, links, references when we find it...
    – PhD
    Commented Apr 26, 2019 at 22:40
  • 1
    what is your job and how exactly this situation prevents you from doing it? Commented Apr 26, 2019 at 22:42
  • 1
    I suggest you read the post and answers, and not just judge a post by its title... There are several answers that apply to the situation you describe here, I am sure they will at least give you some pointers... perhaps it requires several google searches, but in a bigger sense "google it" means "try finding it on your own"
    – DarkCygnus
    Commented Apr 26, 2019 at 22:43
  • 3
    Is everyone in the meeting actually necessary? Including junior engineers in a design meeting when they lack the background to understand the design decisions being made doesn't seem productive. It would seem to make more sense to limit design meetings to folks that are up to speed on the background and to separately work to bring junior engineers up to speed. That may involve a dedicated "intro to x" meeting, it may involve some sort of official or semi-official training/ mentorship program where they are given books and articles to read and other opportunities to learn. Commented Apr 26, 2019 at 23:03

3 Answers 3


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.

  • The meetings have a specific goal and only those that need to be there are invited. It’s when we’re talking about a specific design and others may not “get it” is when the problems arise. A current suggestion is to further streamline the meeting agenda and table discussions of meta-learning to see if it’ll help.
    – PhD
    Commented Apr 27, 2019 at 1:22
  • 2
    It seems that your colleagues who are less experienced might benefit from some sort of training (internal or external) on the topics that are the biggest pain points to your team. It might be reasonable to invest some time into organizing this, perhaps a 2-3 day seminar to allow these colleagues to catch up with the rest of you.
    – xyz
    Commented Apr 27, 2019 at 12:30

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .